emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] Thanks for Lilypond export (and minor comments)


From: Bastien
Subject: Re: [O] Thanks for Lilypond export (and minor comments)
Date: Fri, 08 Jul 2011 11:08:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Hi Nick,

Nick Dokos <address@hidden> writes:

> I'm not sure whether I posted this before but if you haven't seen
> it before, it's probably worth reading:
>
>    http://nvie.com/posts/a-successful-git-branching-model/

Nice read -- thanks.

In fact, we *do* have a documented process for important fixes 
that need to go to the maint branch.  See README_maintainer:

,----[ Minor releases ]
| The release number for minor releases look like this:  =7.13.01=
| 
| Minor releases are small amends to main releases.  Usually they fix
| critical bugs discovered in a main release.  Minor bugs are not
| fixed - they will be adressed in the next main release.  Only the fix
| to the bug is bundled into a release, without the main development
| work going on in the master branch.  Since the bug fix will also be
| needed in the master branch, usually the fix is made in master and
| then cherry-picked into maint.  When this is done, a release is made
| from maint with this command:
| 
| : make fixrelease TAG=7.13.01
`----

So in the case Eric raised, I would ideally cherry-pick important fixes
from the master branch to the maint branch then make a release based on
this maint branch.

I think this makes sense when the master (development) branch is quite
unstable, with several untested features.

As long that I'm confident many testers use the latest master branch, 
I'm reluctant to go through the hassle of cherry-picking commits...  
and just release a minor release with all latest dev from master.

Call me lazy, but I'd rather keeping things simple here.

-- 
 Bastien



reply via email to

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