From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Thanks for Lilypond export (and minor comments) Date: Fri, 08 Jul 2011 11:08:07 +0200 Message-ID: <87k4bt3zt4.fsf@gnu.org> References: <9E8B5700-6008-4832-ACE1-BF471F129E0E@beds.ac.uk> <87sjqhdfn3.fsf@gnu.org> <874o2x1rfz.fsf@gmail.com> <87oc15nvv1.fsf@gnu.org> <17595.1310108424@alphaville.dokosmarshall.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:42094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qf72G-0002kU-KD for emacs-orgmode@gnu.org; Fri, 08 Jul 2011 05:07:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qf72D-0004I1-9u for emacs-orgmode@gnu.org; Fri, 08 Jul 2011 05:07:44 -0400 Received: from mail-fx0-f52.google.com ([209.85.161.52]:62826) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qf72C-0004Hl-Lf for emacs-orgmode@gnu.org; Fri, 08 Jul 2011 05:07:41 -0400 Received: by fxd18 with SMTP id 18so1724365fxd.39 for ; Fri, 08 Jul 2011 02:07:39 -0700 (PDT) In-Reply-To: <17595.1310108424@alphaville.dokosmarshall.org> (Nick Dokos's message of "Fri, 08 Jul 2011 03:00:24 -0400") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: nicholas.dokos@hp.com Cc: Torsten Anders , emacs-orgmode@gnu.org Hi Nick, Nick Dokos 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