From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Thum Subject: Re: [DEV] New git workflow Date: Wed, 21 Mar 2012 09:46:49 +0100 Message-ID: <4F699579.2090505@gmx.de> References: <87mx7cf613.fsf@altern.org> <4F69063F.40600@gmx.de> <874ntilxh9.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:35297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAGI0-0002UE-HJ for emacs-orgmode@gnu.org; Wed, 21 Mar 2012 03:49:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SAGHv-0000py-Ad for emacs-orgmode@gnu.org; Wed, 21 Mar 2012 03:49:00 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:33608) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1SAGHv-0000pg-0D for emacs-orgmode@gnu.org; Wed, 21 Mar 2012 03:48:55 -0400 In-Reply-To: <874ntilxh9.fsf@Rainer.invalid> 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: Achim Gratz Cc: emacs-orgmode@gnu.org Hi Achim, On 03/20/2012 11:27 PM, Achim Gratz wrote: > Sorry, but cherry-picking into multiple release branches would simply > not be a sane development model for a small project like orgmode. I just wanted to make sure it's considered. Whether multiple branches are involved depends mainly on what releases one intends to maintain. The nice thing in the model is the gradual maintenance: A really critical fix could see more backports than a nicety. > >> I guess a decision should mostly be based on how significant the use >> case "back-port fix" is to org-mode. The "safer master" role of maint >> could of course be retained in a stable branch which points to >> something like master@{1 month ago}. > > Any point in the past is no safer than today's master. The stability > that maint should provide to users is with regards to the feature set, > i.e. no gratuitous changes between releases. Ooops, I just wanted to illustrate that "stable" is typically behind master - ultimately it should be a concious decision what is "stable". I like the goal maint is set to achieve, I'm just not convinced regular merges are a good way to ensure it - after all, merges include everything in a branch. If there are no doubts about that on your side, I'm fine. Cheers, Simon