gtg team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Sun, Jan 31, 2010 at 10:30:49AM +0100, Bertrand Rousseau wrote:
> On Sun, Jan 31, 2010 at 2:05 AM, Luca Invernizzi <invernizzi.l@xxxxxxxxx>wrote:
> 
> > Hello GTG devs,
> >  currently,  the TRUNK branch is freezed. Therefore, I'm fixing bugs and
> >  adding new stuff only locally, and probably someone else is doing that
> >  too.
> >  This is not really nice because:
> >    - If two of us change the same part of code, merging can be a hassle
> >    - I tend to forget to commit them after (I'm nearly a stackless
> >    state machine, that's why I need GTG)
> >
> > I looked around a bit to see how other projects solve this issue, and it
> > seems
> > that most of them create a revision branch at every release. This way,
> > trunk is left open and the patches which solve bugs for the "freezed"
> > release are applied to both branches. Plus, if a critical bug is found
> > in an already released version, it's easy to patch it and distribute the
> > update.
> >
> > Tell me what you think about that.
> >  Luca
> >
> >
> I agree with what you suggest. I think it would be definitely be more
> convenient.

Yep, a lot of projects do that; it's an effective approach for a project
of gtg's size.  At the point you want to establish a freeze to prepare
for release, you establish a new branch for the release, and cherrypick
bugfixes from trunk onto it until it is ready for release.  After
release, you can continue to accumulate additional cherrypicked bug
fixes, and put out out point releases (0.2.1, 0.2.2) with the bug fixes.

Launchpad permits tracking this type of workflow.  You set your 'series'
to the major releases (0.2.x, 0.3.x, ...) and milestones to each of the
point releases (along with any alphas/betas/rcs).  You could look at
Inkscape (http://launchpad.net/inkscape/) as an example of this
style.  This lets people target branches, bug reports,
etc. accordingly.

Bryce