-
Notifications
You must be signed in to change notification settings - Fork 650
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Commit message can bump major version twice in GitFlow #2667
Comments
Thank you very much @MikeFlowerdewAveva that you have created this integration test. It is so much easier to understand your scenario. In my opinion your issue is solved in version 6.x already. I'm not sure in which increment exactly but I have tested it with the latest version on main. Please try 6.0.0-beta.1 preview release. Happy branching! |
🎉 This issue has been resolved in version 6.0.0-beta.2 🎉 Your GitReleaseManager bot 📦🚀 |
The problem
I dont' know if this is intended use, but commit-message incrementing doesn't seem to work with GitFlow. I want to add a commit message with
semver:major
at the point of the breaking change, to allow correct major version assignments for system testing between releases. The documentation around manual increments doesn't appear to give any caveats in this regard.I've supplied a test illustrating this issue. This isn't exactly how I hit it, but is simpler and easier to understand. Instead of being based on
2.0.1
, the assigned FullSemVer is3.0.0-beta.1+6
.The immediate cause seems to be BaseVersionCalculator.FixTheBaseVersionSourceOfMergeMessageStrategyIfReleaseBranchWasMergedAndDeleted(), which takes the merge commit message from release 2 and reassigns the merge base to the original branching commit for
release/1.0.0
. This in turn causes thesemver
commit message to be counted again while incrementing from the base version. This code affects commit counting, which is fair enough, but I'm surprised it's allowed to effectively modify the major version number.Workaround
I can avoid the problematic method by having a single
release/X.Y.Z
branch anywhere in the repository. However, I'm not generally a fan of relying on side-effects like this.The double-bump effect also disappears in the release after the one with the major increment, i.e. there is no triple-bump. However, in my actual use-case (see below) I'm still stuck with an unwanted major version increment.
Test code
Footnote
In our actual repo, we implement GitFlow with a merge from
main
back todevelop
at each release, which I understand is fairly common. This issue then appears ondevelop
, meaning it is not only an issue for hotfixes. However, I think the above example is easier to explain and reason about.The text was updated successfully, but these errors were encountered: