Branching strategy for git

[John Ralls]

On Mar 25, 2014, at 10:46 AM, Derek Atkins <warlord at MIT.EDU> 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.

It will be. When we’re ready to release 2.8, the ‘maint’ branch will be renamed to ‘2.6’; when we release 2.8.3, we’ll create a new ‘maint’ branch from ‘master’. We could even do that at 2.8.0, because merging ‘maint’ into ‘master’ isn’t a big deal until ‘master’ diverges. Waiting is a hold-over from SVN, which until 1.7 didn’t allow that.

Why not call it ‘2.6’ right away? Just to make maintaining the wiki easier: If ‘maint’ is always the current bug-fix branch, then the policy can say that and not have to be changed every 3 years.

Regards,
John Ralls