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: Next release from master Date: Mon, 18 Jan 2016 17:54:34 +0200 Message-ID: <83bn8ievd1.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1453132519 23585 80.91.229.3 (18 Jan 2016 15:55:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Jan 2016 15:55:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 18 16:55:10 2016 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 1aLC94-0005yI-Hq for ged-emacs-devel@m.gmane.org; Mon, 18 Jan 2016 16:55:06 +0100 Original-Received: from localhost ([::1]:60416 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLC93-000600-Rq for ged-emacs-devel@m.gmane.org; Mon, 18 Jan 2016 10:55:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLC8X-0005to-R9 for emacs-devel@gnu.org; Mon, 18 Jan 2016 10:54:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLC8U-0002W9-JQ for emacs-devel@gnu.org; Mon, 18 Jan 2016 10:54:33 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:32781) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLC8U-0002W5-Fu; Mon, 18 Jan 2016 10:54:30 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1242 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aLC8S-00014d-2Y; Mon, 18 Jan 2016 10:54:28 -0500 In-reply-to: (message from Stefan Monnier on Sun, 17 Jan 2016 18:04:17 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:198255 Archived-At: > From: Stefan Monnier > Date: Sun, 17 Jan 2016 18:04:17 -0500 > > I noticed that etc/NEWS on master is setup for "25.2" being the next > release from master. Is that indeed the intention? I think we don't know yet. > My own conclusion based on how things worked during Emacs-24.N was that > we're better off incrementing the major version every time there are new > features. IOW the next release form master should be called 26.1 and > 25.N should be kept for a bugfix-only releases from the emacs-25 branch. There's a new kid on the block (not me, I'm anything but "new" ;-), and he needs time to make up his mind about what exactly will be released, when, and how. What you see now was asked and answered: From http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01372.html: > >>>>> Eli Zaretskii writes: > > > We should now change master to identify itself as version 25.1.50 or maybe > > even 26.0.50. OK? > > Let's go with 25.1.50 for now. > It's not tremendously important, but the way we've done it in the past > ended up with all kinds of minor inconveniences when we suddenly decide > that we need another bugfix release: e.g. having to update all > "make-obsolete" calls, not to mention all the "will be fixed in (or > added to) Emacs-NN.MM" already posted in debbugs, mailing-lists, > stackoverflow, forums, and newsgroups which suddenly become lies. I don't see any good way around these issues, as long as the decisions are dynamic and not subject to some fixed deterministic algorithm. Even if we somehow force ourselves to make the decision now, there will be similar issues in the other direction, see Michael's email down-thread. These issues are not a catastrophe, making those changes (where necessary) is a simple (though boring and ungrateful) job.