From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Future release schedules (was: make change-history on non-master branches) Date: Fri, 20 Nov 2015 20:04:17 +0200 Message-ID: <83h9kg5yzi.fsf@gnu.org> References: <831tbqc4pc.fsf@gnu.org> <9ta8qb5gcc.fsf@fencepost.gnu.org> <83egfn9nmp.fsf@gnu.org> <83bnar9mcd.fsf@gnu.org> <83r3jm7zw1.fsf@gnu.org> <87lh9tkby8.fsf@isaac.fritz.box> <83wptd7mif.fsf@gnu.org> <83mvu96qjk.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1448042689 27053 80.91.229.3 (20 Nov 2015 18:04:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Nov 2015 18:04:49 +0000 (UTC) Cc: rgm@gnu.org, eggert@cs.ucla.edu, deng@randomsample.de, lekktu@gmail.com, emacs-devel@gnu.org, schwab@suse.de To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 20 19:04:40 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zzq36-0007SO-6j for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2015 19:04:40 +0100 Original-Received: from localhost ([::1]:48993 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zzq35-0007bj-La for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2015 13:04:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54507) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zzq31-0007Zm-Ds for emacs-devel@gnu.org; Fri, 20 Nov 2015 13:04:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zzq2x-0001BH-7w for emacs-devel@gnu.org; Fri, 20 Nov 2015 13:04:35 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:58086) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zzq2w-0001BD-RP; Fri, 20 Nov 2015 13:04:31 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NY400800KUX4O00@mtaout26.012.net.il>; Fri, 20 Nov 2015 20:07:30 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY40003KL0HS080@mtaout26.012.net.il>; Fri, 20 Nov 2015 20:07:29 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194870 Archived-At: > From: John Wiegley > Cc: Juanma Barranquero , schwab@suse.de, eggert@cs.ucla.edu, rgm@gnu.org, deng@randomsample.de, emacs-devel@gnu.org > Date: Fri, 20 Nov 2015 08:38:35 -0800 > > >>>>> Eli Zaretskii 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.