From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines Date: Wed, 2 Nov 2011 15:18:35 +0100 Message-ID: References: <87pqhrih3s.fsf@gmail.com> <87zkgvgxe7.fsf@gmail.com> <1405.1319147324@alphaville.dokosmarshall.org> <87zkgvfhra.fsf@gmail.com> <2127.1319148505@alphaville.dokosmarshall.org> <87vcrjfgt1.fsf@gmail.com> <80sjmmvm60.fsf@somewhere.org> <4EA129DB.4070006@christianmoe.com> <8762ji5jr6.fsf@gmail.com> <4EA1D4F9.5010302@christianmoe.com> <4ea1de9c.67b4ec0a.553d.122a@mx.google.com> <87aa8t10np.fsf@gmail.com> <4ea5a95b.059dec0a.606e.0c92@mx.google.com> <874nypkn6y.fsf@gmail.com> <87obwwkia5.fsf@gmail.com> <87boswk4vj.fsf@gmail.com> <8627.1320157576@alphaville.dokosmarshall.org> <9991.1320159724@alphaville.dokosmarshall.org> <87hb2nj2ic.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0016369fa10ac8a1ca04b0c1259b Return-path: Received: from eggs.gnu.org ([140.186.70.92]:49195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLbeI-0003PW-2Y for emacs-orgmode@gnu.org; Wed, 02 Nov 2011 10:18:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLbeG-00054c-KI for emacs-orgmode@gnu.org; Wed, 02 Nov 2011 10:18:38 -0400 Received: from mail-qy0-f176.google.com ([209.85.216.176]:43026) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLbeG-00052o-Eq for emacs-orgmode@gnu.org; Wed, 02 Nov 2011 10:18:36 -0400 Received: by qyk29 with SMTP id 29so286408qyk.0 for ; Wed, 02 Nov 2011 07:18:36 -0700 (PDT) In-Reply-To: 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: Brian Wightman Cc: emacs-orgmode@gnu.org --0016369fa10ac8a1ca04b0c1259b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 2, 2011 at 1:57 PM, Brian Wightman wrote: > On Tue, Nov 1, 2011 at 10:17 AM, Eric Schulte > wrote: > > This is also after all the development repository, and while I do try > > very hard never to break this head of this repository at the same time I > > think it is an acceptable place to try out new functionality. > > Given that a common recommendation for a bug fix is to 'try commit > blah blah blah', would it make sense to have bug fixes go onto a > 'maint' branch (as well as master), and new features / changed > features stay on the master branch? At the time when 'master' is > ready for a new official release, it could then be merged into 'maint' > to create the next stable point for bug fixes. > > Adding features on the same branch as bug fixes, when 'official > releases' are not made frequently seems to be a formula for > frustration. > Added features are not that much of a problem, but changes which affect backward compatibility are. But there were not many in the past that I am aware of. Cheers, Rainer > Thoughts? > > Brian > > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D): +49 - (0)3 21 21 25 22 44 email: Rainer@krugs.de Skype: RMkrug --0016369fa10ac8a1ca04b0c1259b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Nov 2, 2011 at 1:57 PM, Brian Wi= ghtman <= MidLifeXis@wightmanfam.org> wrote:
On Tue, Nov 1, 2011 at 10:17 AM, Eric Schulte <schulte.eric@gmail.com> wrote: > This is also after all the development repository, and while I do try<= br> > very hard never to break this head of this repository at the same time= I
> think it is an acceptable place to try out new functionality.

Given that a common recommendation for a bug fix is to 'try commi= t
blah blah blah', would it make sense to have bug fixes go onto a
'maint' branch (as well as master), and new features / changed
features stay on the master branch? =A0At the time when 'master' is=
ready for a new official release, it could then be merged into 'maint&#= 39;
to create the next stable point for bug fixes.

Adding features on the same branch as bug fixes, when 'official
releases' are not made frequently seems to be a formula for
frustration.

Added features are not that much of a= problem, but changes which affect backward compatibility are. But there we= re not many in the past that I am aware of.
=A0
Cheers,

Rainer=



Thoughts?

Brian




--
Rainer M. Krug, = PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phy= s. (Germany)

Centre of Excellence for Invasion Biology
Stellenbos= ch University
South Africa

Tel : =A0 =A0 =A0 +33 - (0)9 53 10 27 44
Cell: =A0 = =A0 =A0 +33 - (0)6 85 62 59 98
Fax (F): =A0 =A0 =A0 +33 - (0)9 58 10 27 = 44

Fax (D): =A0 =A0+49 - (0)3 21 21 25 22 44

email: =A0 =A0 = =A0Rainer@krugs.de=

Skype: =A0 =A0 =A0RMkrug

--0016369fa10ac8a1ca04b0c1259b--