Branching strategy for git

[Derek Atkins]

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

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