Branching strategy for git

Derek Atkins warlord at MIT.EDU
Wed Mar 26 12:53:36 EDT 2014

John Ralls <jralls at> writes:

> 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.

I guess I didn't realize (or contemplate) we could easily rename the
branch later -- but I suppose that makes sense based on the way that git
handles branches.

I'm mostly just thinking about way way way down the road someone wanting
to come back and see the work done on e.g. the 2.6 maint branch, when
"maint" isn't 2.6 anymore.

> Regards,
> John Ralls


       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list