Allow user to manually specify the next version number #1192
Description
Activity
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
Still in backlog
Reacted by Micael JarniacIt has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
No update yet, still in backlog.
Reacted by Micael JarniacIt has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
Still in backlog
It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
Feature Request
Description
It may be useful for some use-cases to allow the user to manually specify the next version number.
Use cases
One such use-case would be the "Epoch SemVer" idea, where the MAJOR version behaves slightly differently in the case of a "notorious" update, increasing by 100 instead of by 1, for example.
Another use-case would be when the repo is in a broken state, and PSR can't figure out what to do. Being able to override the next version entirely would allow the user to get out of these broken states more easily. This would have helped me in #1188, for example.
Possible implementation
semantic-release version --force 1.2.3 to force the next version to be v1.2.3.
This would then check if the provided version isn't lower than the current one, and if valid, bump straight to it.
Alternative solutions
There are flags to force bumps to MINOR, MAJOR, or PATCH, but these will only increase the specified portion by 1, which isn't suitable for all use-cases.
The user could also manually work with Git and such to try to craft a scenario where semantic-release version will have the desired result, but it'd be error-prone and tricky to do.
Another option would be to manually perform all the automated steps PSR would take, but this is once again error-prone and tricky.