From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Updating release version to 22.1 Date: Tue, 08 Feb 2005 16:58:41 +0100 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1107878989 19922 80.91.229.2 (8 Feb 2005 16:09:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 8 Feb 2005 16:09:49 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 08 17:09:49 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CyXvj-0003lg-Le for ged-emacs-devel@m.gmane.org; Tue, 08 Feb 2005 17:09:35 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CyYA5-0006fB-Qt for ged-emacs-devel@m.gmane.org; Tue, 08 Feb 2005 11:24:25 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CyY8Z-0006Gt-9P for emacs-devel@gnu.org; Tue, 08 Feb 2005 11:22:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CyY8N-0006Am-5U for emacs-devel@gnu.org; Tue, 08 Feb 2005 11:22:41 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CyY8L-00066I-4f for emacs-devel@gnu.org; Tue, 08 Feb 2005 11:22:37 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CyXlC-0005zw-OR for emacs-devel@gnu.org; Tue, 08 Feb 2005 10:58:42 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1CyXhp-0004eg-SC; Tue, 08 Feb 2005 10:55:14 -0500 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Tue, 08 Feb 2005 16:05:24 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:33089 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33089 storm@cua.dk (Kim F. Storm) writes: > David Kastrup writes: > >>> So the CVS version will be updated to 22.1.-999, and pretests will >>> be numbered 22.1.-998 , 22.1.-997 , etc. >>> >> The numbering scheme may be geeky, but for all practical purposes >> it will cause trouble. Consider this a strong objection. I would >> appreciate getting at least the impression that the above reasons >> have registered before I get overridden. > > We have discussed this before, and to the average user, our > "current" scheme where the cvs version to be released as 21.4 is > named 21.3.50 is also very confusing. I don't see how this would justify replacement with a scheme that is much more confusing. > I would much rather like to see some descriptive text in there, e.g. > > 22.1.DEV > > 22.1.PRE-1 > 22.1.PRE-2 > > etc. when working towards a release 22.1 I think that any suffix should not be separated by a period, but instead 22.1-pre1 would seem appropriate. When we are not particularly passing out something intended to be an approximation to a release, I'd rather have a version number numerically below the actual release, something like 21.3-dev20050301 though in our current case I think 22.0-dev20050301 as a precursor to 22.1 would seem a bit more intuitive. There is a lot of advice of the sort "will be supported in Emacs 21.4 or later", and "will be supported in Emacs 22" would give us better possibilities for being more or less accurate without having to eat our words too often. > Subsequent bug fixes could be named > > 22.1-1 That is not a good idea since the -%d tags are already used in many package systems (RPM/Debian) for tagging fixed packages (new configure options, different package layouts, packaging errors and so on). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum