Release version numbers getting reused in Long-Term Release Branches

[bcparkison]

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?

[jimeh]

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 2.9.8 tag on the release-2.9 branch was created after the 2.11.4 tag on the master branch.

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.

[mriegler]

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?

[jimeh]

@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 release-2.9 branch. Also if you were to just merge the release-2.9 branch into master you would kind of be trying to restore master back to a similar state it was in back in version 2.9.

So in terms of what happens to release-2.9 branch after you've tagged the release, you can either leave it around or delete it. If you do delete it, you can easily create it again from the latest 2.9.x tag if another fix comes up that needs to be applied to the 2.9.x version.