Branching and tagging best practices

7
From experience I know that it is very important to set clear branching and tagging guidelines for a project and that they depend on the type of project. I am currently involved in a project that has one version in production (so not Commercial-Off-The-Shelf). Where there will be major releases to satisfy the large changes and minor releases to fix bugs and implement minor changes. I do expect that it will be necessary to allow for branching of the minor releases to allow changes that are uncertain to fit in a minor release to be developed separately. And I also want to anticipate the need of patches on the mainline to fix critical bugs. I am looking for best practices on how to branche and tag in this case and want to anticipate for what might seem a rather complex setup so that I can always simplify when possible instead of the other way around. My intended setup is: When tagging the mainline for a major release I intend to tag it as <major releasenr="">.0.0.<rev>. E.g. 2.0.0.28. Does that seem right? When creating a branche for a minor release I intend to name it [major releasenr]-SP. E.g. 2-SP When tagging a minor release I intend to tag it as [major releasenr].[minor releasenr].0.[rev]. E.g. 2.1.0.40 When creating a branche of the minor release I intend to name it [minor release name]-[change indicator]. E.g. 2-SP-RFC1012 When creating a branche for patch I intend to name it [minor releasenr]-[patchindicator]. E.g. 2.2-INC0123. When tagging the patch I intend to tag it as [major releasenr].[minor releasenr].[patchnr].[rev]. E.g. 2.3.5.65 Does all this make sense? Are there best practices? If not I hope this thread will develop into one.
asked
1 answers
5

Your setup looks reasonable to me. The tags you propose sound exactly right.

You could simplify by implementing minor releases in the main line. You can use feature branches for developing large features that will end up in a major release to keep them out of the mainline until they are done.

For patches you create a maintenance branch originating in the tag of the version you want to patch. After fixing in the maintenance branch you can merge back to the main line.

My advice would be to try and keep it as simple as possible. It is cool that you have a lot more freedom in 3.0.0 but it is easy to shoot yourself in the foot :-)

answered