lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: branching


From: Graham Percival
Subject: Re: branching
Date: Sat, 16 Apr 2011 00:23:54 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, Apr 15, 2011 at 07:11:21PM -0400, address@hidden wrote:
> 
> I agree - it is for this reason that I feel the only two solutions are to:
> 
> (1)   Freeze pushes to the master branch save ones that are
> explicitly authorized by Graham.

Oh god no.

> (2)   Keep working at our normal pace, but split off stable
> versions to which only bug fixes will be applied.

(3) any "big" change -- say, any patch that takes longer than 6
hours to write -- is done on a separate branch, and only merged
with master once we have good reason to believe that it's
finished.

Git is designed to handle tons of branches.  Painless branching
and merging is pretty much the biggest feature point of git!

In our recent history, I'd say that the MIDI rewrite and beam
avoidance code rewrite are ideal candidates for being worked on
separate branches.  NB: I'm not talking about a single
"development" branch.  I'm talking about having a dozen separate
branches, one for each feature.  You and Han-Wen could have work
on the dev/beaming branch.  Jan and anybody interested could have
worked on the dev/midi branch.  You and Reinhold could have worked
on the dev/footnotes branch.  Etc.

Yes, there will probably still be unexpected problems when we
finally merge one of those "feature" branches with master... but
by isolating the "new feature" development work from master, we'll
have a more stable central branch, and we can test a specific new
features after merging in a much more focused way.

Cheers,
- Graham



reply via email to

[Prev in Thread] Current Thread [Next in Thread]