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: Wed, 09 Feb 2005 01:32:11 +0100 Message-ID: References: <87vf92sqby.fsf@marant.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1107909789 13318 80.91.229.2 (9 Feb 2005 00:43:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 9 Feb 2005 00:43:09 +0000 (UTC) Cc: miles@gnu.org, rms@gnu.org, =?iso-8859-1?q?J=E9r=F4me_Marant?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 09 01:43:09 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Cyfwe-0003R3-VS for ged-emacs-devel@m.gmane.org; Wed, 09 Feb 2005 01:43:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CygB5-00033Z-GS for ged-emacs-devel@m.gmane.org; Tue, 08 Feb 2005 19:57:59 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cyg91-0002uy-DC for emacs-devel@gnu.org; Tue, 08 Feb 2005 19:55:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cyg8n-0002ou-7d for emacs-devel@gnu.org; Tue, 08 Feb 2005 19:55:39 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cyg8m-0002jN-95 for emacs-devel@gnu.org; Tue, 08 Feb 2005 19:55:36 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CyfmG-00059G-8i for emacs-devel@gnu.org; Tue, 08 Feb 2005 19:32:20 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1Cyfik-0006m1-4b; Tue, 08 Feb 2005 19:28:42 -0500 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Wed, 09 Feb 2005 01:17:30 +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:33105 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33105 storm@cua.dk (Kim F. Storm) writes: > Miles Bader writes: > >> On Tue, 08 Feb 2005 22:18:41 +0100, J=E9r=F4me Marant w= rote: >>> What's the rational for not using 22.0.x for development versions? >>> It would be so much simpler ... > > Because it - IMO - is confusing. > > Right now (or two days ago) we had released 21.3 and were working on > the trunk towards a release 21.4. > > But the version on the trunk is numbered 21.3.50 > > Typically, the user who built 21.3 has a version called 21.3.1 or > 21.3.2 which is pretty close to 21.3.50 Ok, I forgot about _build_ numbers. Doing a quick locate, I find /usr/local/emacs-21/share/emacs/21.3.50/etc/DOC-21.3.50.30 /usr/local/emacs-21/share/emacs/21.3.50/etc/DOC-21.3.50.31 /usr/local/emacs-21/share/emacs/21.3.50/etc/DOC-21.3.50.32 Maybe _build_ numbers should be tagged off with -%d instead of .%d after all. Yes, this is the same numbering scheme that RPMs and other packages tend to use, but they use it for _exactly_ that purpose: to indicate build numbers (and it does not usually get reflected in an file names within the package). > But if we could agree that we always release major versions from the > trunk and each major release gets a new major number 22.1, 23.1, > etc, I see no problem using 22.0.0, 23.0.0, etc as development > versions, ans 22.0.1, 22.0.2, etc for the pretests. > > Bug fixes would be released from branches, and be named 22.2, 22.3, > etc. > > Looking at past history, this wont cause major number inflation -- > if lucky, we will release 30.1 in 2030 which isn't too bad :-) > > That is indeed a simple scheme which I would support. > > So Richard, if we could agree that major releasees from the trunk > always gets a new major number, we will get a simple numbering > scheme without the risk of accidentally using a "reserved" release > number as you just did. > > It would be MUCH LESS HASSLE for future work if we implemented this > scheme right away. Seconded. --=20 David Kastrup, Kriemhildstr. 15, 44793 Bochum