Branching strategy for git
warlord at MIT.EDU
Wed Mar 26 12:53:36 EDT 2014
John Ralls <jralls at ceridwen.us> 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
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.
> John Ralls
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord at MIT.EDU PGP key available
More information about the gnucash-devel