Branching strategy for git

[Geert Janssens]

On Tuesday 25 March 2014 13:46:17 Derek Atkins wrote:
> John Ralls <jralls at ceridwen.us> writes:
> > On Mar 25, 2014, at 8:15 AM, Geert Janssens <janssens-geert at telenet.be> wrote:
> >> If no one beats me to it I'll try to adapt the git wiki page with
> >> this info in the coming days.
> > 
> > OK. The main change seems to me to be that instead of making a '2.6'
> > branch next week I'll be making a 'maint' branch.
> 
> Part of me thinks I'd rather see the maint branch called 2.6 -- in
> order to differentiate the maintenance of 2.6 vs the maint of 2.8,
> 3.0, etc down the road.
> 
> -derek

The git workflow proposes to only use explicit version numbers in the branches the moment 
you need two maintenance branches. So at the point where we want to support both a 2.6 and 
a 2.8 release series. Maint itself always rolls over from previous to most recent release series.

In our typical workflow so far the overlap has always been very short - one or at most two point 
releases. So we only need to differentiate between maintenance branches for a relatively short 
period of time.

Apart from that the release tags will also quickly reveal which branch you're on.

But technically it's just a game of what's in a name.

Geert