-
Notifications
You must be signed in to change notification settings - Fork 7
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
Release version numbers getting reused in Long-Term Release Branches #20
Comments
Potentially 8.iv isn't clear enough. In the example given 2.9.7 is the latest 2.9.x release, meaning there never was a 2.9.8 release, the version was bumped directly from 2.9.7 to 2.10.0. Hence the new 2.9.8 release containing our imaginary security fix doesn't conflict with any previously existing release tag. I quickly threw together the diagram below to outline how this specific case is supposed to work. The order of events/tags is from bottom to top, meaning the I hope this answers your question, and please don't hesitate to ask if you have any further questions about this, or any other questions about Common-Flow in general. Common-Flow is still evolving and I'm more than happy to take on and consider any feedback, suggestions and/or requests. For now I'll leave this issue open as I want to try and make the wording of 8.iv a little bit clearer. |
Assuming the fix added in 2.9.8 was still present in 2.11.4/current master, would you merge release-2.9 back into master or would you cherry-pick the fix? |
@mriegler If the fix applied to 2.9.8 needs to be applied to 2.11.4/master, the fix itself should have been developed there, and then backported into the newly created So in terms of what happens to |
I'm evaluating branching models for my company as we transition to a git workflow, and really like this proposal. However, my reading of it implies that release tags get reused in long term release branches. In particular, this statement in 8.iv:
Long-term release branches for maintenance releases of older versions MUST be created from the relevant release tag. For example if the master branch is on version 2.11.4 and there is a security fix for all 2.9.x releases, the latest of which is "2.9.7". Create a new branch called "release-2.9" off of the "2.9.7" release tag. The security fix release will then end up being version "2.9.8".
Is the 2.9.7 release tag on the master branch? If so, wouldn't the next commit to the master branch be 2.9.8? And, now the first commit to the release-2.9 branch is also 2.9.8? Or, did I misinterpret some of the statements?
The text was updated successfully, but these errors were encountered: