Branching strategy for git
janssens-geert at telenet.be
Tue Mar 25 13:58:36 EDT 2014
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.
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.
More information about the gnucash-devel