python-semantic-release
Allow invoke versions > 1.x in setup.py
The problem
Restricting invoke to invoke>=1.4.1,<2 in setup.py causes dependency resolution issues.
The upper bound to invoke versions was introduced in commit 0a6f8c38 (along with a number of other version restrictions, see Additional context below). Apparently this was done as a preventive measure without any actual, known incompatibilities.
Invoke (https://github.com/pyinvoke/invoke) has since released version 2.0.0 (in January 2023, it is now at v2.1.3). As a result, projects which use python-semantic-release and invoke as direct dependencies now would require to explicilty select an older version of invoke to meet the version constraint imposed by python-semantic-release.
Expected behavior
Allow use of invoke >= v2.0.0.
From what I've seen in the code (it only ever seems to use invoke.run(...)), this should not be a problem.
Additional context
Commit 0a6f8c38 introduced a number of other constraints to the upper bounds of dependency versions:
click>=7.0,<8
gitpython>=3.0.8,<4
invoke>=1.4.1,<2
semver>=2.8.0,<3
twine>=3.0.0,<4
requests>=2.21,<3
python-gitlab>=1.10.0,<2
Some of those might actually be necessary, but it might be worth to review those, too. A number of projects have now moved to versions past those bounds (i.e. click v8.1.3, semver v3.0.1, twine v4.0.2, python-gitlab v3.15.0).
Click, and semver are probably not as important, since the projects are libraries. But invoke, python-gitlab and twine are CLI tools meant for direct (interactive) use by developers and an arbitrary restriction of their versions which can be used in together with python-semantic-release seems unecessary.
I also just noticed that these dependency issues have already been addressed in v8.x. So it might not be worth fixing this for v7.x (depending on the planned schedule for releasing a stable v8 version).
