[Top][All Lists]

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

Re: Future release schedules (was: make change-history on non-master bra

From: Eli Zaretskii
Subject: Re: Future release schedules (was: make change-history on non-master branches)
Date: Fri, 20 Nov 2015 20:04:17 +0200

> From: John Wiegley <address@hidden>
> Cc: Juanma Barranquero <address@hidden>,  address@hidden,  address@hidden,  
> address@hidden,  address@hidden,  address@hidden
> Date: Fri, 20 Nov 2015 08:38:35 -0800
> >>>>> Eli Zaretskii <address@hidden> writes:
> > Alas, it's not just the pretest, it's the entire life time of the release
> > branch. That life time is just starting for the emacs-25 branch; I'm quite
> > certain that at lease Emacs 25.2 and probably also 25.3 will be delivered
> > from that branch. That's another 2 years. I don't think we want to wait that
> > long for your useful corrections and general loving care of ChangeLog.2 ;-)
> >
> > I hope we will find a better solution to this.
> Once 25.1 is out -- and this could take up to six months -- I'd like us to
> switch to a different process for point releases: A new .x release every two
> months, with whatever bug fixes have been accomplished in that interim.
> Once the emacs-25 branch is stable, say at 25.2, primary development would
> resume on master towards emacs-26. However, bugs will continue to be fixed and
> back-ported to emacs-25, with regular point releases from that branch, until
> it's stable enough to no longer need our attention. Beyond that point, it
> becomes a frozen branch -- unless a critical bug fix occurs justifying a point
> release solely for that fix.

That's what we did with emacs-24 branch as well.  So this is not a new
process, it's a continuation of the process we've been practicing for
several years.

> The intention here is to maximize the utility of Git, now that we have it, and
> to make use of its branching, merging and cherry-picking capabilities to
> accelerate development, without sacrificing attention to stability for the
> current "release series". I like that we have gitmerge.el, for example; I hope
> we can adapt our release process to take full advantage of it.

We had all that before, with Bazaar as well.

reply via email to

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