Maintain two major versions in parallel

[RCerff]

Hello,

while dealing with Semantic versioning I run into the question how to maintain and support two or more versions in parallel.

For example, current version of my product (REST service) is 3.x. At the same time I need to maintain versions 1.y and 2.z. All these old versions need fixes and new functions that don't break the clients that use this old versions.

My opinion is, that all these old versions need their own master/develop/feature branches.

When I look into the example for the Major Release Branch (http://gitversion.readthedocs.io/en/stable/git-branching-strategies/gitflow-examples/) it suggests to delete all the release branches after finishing with it and merge all into a common code base (master)

Following the Semantic Versioning approach, how it is intended to maintain two ore mor major versions in parallel?

[asbjornu]

The normal way to handle this is to create support branches for the older versions you need to support. Since you'll do most development on the latest version, residing in master and develop, you'll most likely only need hotfix/* branches to fix bugs and then merge these against master and the different release/* branches you have.

If you need to do major feature developments on your support branches, you need to treat the support branches as master for each version, skipping develop altogether. If you need develop because you need a synchronisation point between several ongoing feature branches on an old version of the product, it almost sounds like that version warrants separation out into its own repository.

[RCerff]

Thank you Asbjorn, that is the solution. I've overseen that when reading the examples document.