From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.devel Subject: Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.] Date: Wed, 29 Sep 2004 14:29:20 -0500 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <87655wswkv.fsf@trouble.defaultvalue.org> References: <1096291271.415813c757a26@imp6-q.free.fr> <20040927134714.GA20012@fencepost> <87hdphx91c.fsf@trouble.defaultvalue.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1096486276 17144 80.91.229.6 (29 Sep 2004 19:31:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 29 Sep 2004 19:31:16 +0000 (UTC) Cc: "Kim F. Storm" , emacs-devel@gnu.org, rms@gnu.org, J?r?me Marant , Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 29 21:30:59 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CCkAF-0001FT-00 for ; Wed, 29 Sep 2004 21:30:59 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CCkGb-0005rI-4b for ged-emacs-devel@m.gmane.org; Wed, 29 Sep 2004 15:37:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CCkGT-0005rC-Gt for emacs-devel@gnu.org; Wed, 29 Sep 2004 15:37:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CCkGT-0005r0-3K for emacs-devel@gnu.org; Wed, 29 Sep 2004 15:37:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CCkGS-0005qx-VR for emacs-devel@gnu.org; Wed, 29 Sep 2004 15:37:25 -0400 Original-Received: from [66.93.216.237] (helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CCk9w-0008Ux-So; Wed, 29 Sep 2004 15:30:41 -0400 Original-Received: from trouble.defaultvalue.org (omen.defaultvalue.org [192.168.1.1]) by defaultvalue.org (Postfix) with ESMTP id E7E0A3FB1; Wed, 29 Sep 2004 14:30:39 -0500 (CDT) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id 3C2DF410A1; Wed, 29 Sep 2004 14:29:20 -0500 (CDT) Original-To: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Wed, 29 Sep 2004 14:04:33 -0400") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 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 Xref: main.gmane.org gmane.emacs.devel:27677 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27677 Stefan Monnier writes: > Let's ignore version numbers for now. The issue of how to number > them seems to always drift into never ending discussions and I have > no interest in them. Use whichever scheme you like. > > Let's call 21.1 FOO, 21.2 BAR and 21.3 BAZ. > > FOO was a major release, BAR and BAZ were minor releases cur from a > branch (that started off of FOO) and with only safe bugfixes > applied. The only problem I can see with that approach (though it might not matter to you upstream) is that it makes the eventual version number of the more substantial upstream development releases a moving target. Imagine that 21.4 has been relased, and then imagine Jerome and I have made 21.5, 21.6, and 21.7 bugfix releases using backports or patches that were submitted to Debian, that have been approved by the Emacs developers. Now imagine that you're preparing to make a new release from the "main" upstream development branch. What do you call it? If you pick 21.8 and then you're unexpectedly delayed for a month or two (for whatever reason), then we're in trouble if we need to make a bugfix release (imagine a data-destroying bug of some kind that can't wait). We'd need something between 21.7 and 21.8. Of course if you don't the possibility that you might have to keep changing the pending upstream release number whenever we make a minor bigfix release, then there's no problem, but even so, I suspect there's also some value in people being able to easily tell the difference between a truly minor bugfix release and one that's been worked on for (historically) on the order of a year. So while I don't have any special attachment to the X.Y.Z numbering scheme, it's at least one way to fix both those problems. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4