[Opendnssec-develop] A successful Git branching model

[Rick van Rein]

Hi,

> I haven't found anything that describes how you easily use this if you have multiple production versions that you need to maintain (like we do).

Essentially, we want to push a partially-ordered set into a fully-ordered set (or list) structure.  That's like pushing square pegs into round holes.

This is *only* a problem with historic traces, which we will want to retain for future reference, but not to the patches which are pretty much treated as an unordered set in Git (although not as extremist as in Darcs).

> http://stackoverflow.com/questions/18220663/advice-on-multiple-release-lines-and-git-flow-for-git-non-gurus

They say that they split repos, but then introduce a branch naming scheme which would work in one repo as well.

One could wonder if you need to split all branches in a repo, or just the master.  I could imagine this:

1. Right after creating a new, separately supported version X.Y in master, fork a new branch as master-X.Y
2. When version X.Y is updated to X.Y.Z, patch it in the master-X.Y branch
3. Consider the patch for later master-A.B branches, perhaps until the version where they are incompatible or otherwise bad
4. When X.Y matches master, and master-X.Y changed, update master as well

Effectively, master-X.Y becomes a duplicate of master.  The advantage for naming it is that packagers can continue to track that branch throughout the supported life for X.Y, which is not possible when using master itself.  It's a bit like running "Debian Wheezy" versus "Debian Stable".  I'm not sure if the duplication could be avoided with a nifty tagging scheme.


Note that I am not this advanced with Git, these are just ideas.


Cheers,
 -Rick