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 23:34:39 +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 1107902496 6681 80.91.229.2 (8 Feb 2005 22:41:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 8 Feb 2005 22:41:36 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 08 23:41:35 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Cye2Y-0003hs-Uv for ged-emacs-devel@m.gmane.org; Tue, 08 Feb 2005 23:41:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CyeGy-0002mf-I9 for ged-emacs-devel@m.gmane.org; Tue, 08 Feb 2005 17:55:56 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CyeEp-0002E3-Lv for emacs-devel@gnu.org; Tue, 08 Feb 2005 17:53:43 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CyeEj-00026q-BA for emacs-devel@gnu.org; Tue, 08 Feb 2005 17:53:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CyeEY-00022x-JX for emacs-devel@gnu.org; Tue, 08 Feb 2005 17:53:26 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CydwO-0004x5-GK for emacs-devel@gnu.org; Tue, 08 Feb 2005 17:34:40 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1Cydsz-0007cH-Qk; Tue, 08 Feb 2005 17:31:10 -0500 Original-To: =?iso-8859-1?q?J=E9r=F4me_Marant?= In-Reply-To: <87vf92sqby.fsf@marant.org> ( =?iso-8859-1?q?J=E9r=F4me_Marant's_message_of?= "Tue, 08 Feb 2005 22:18:41 +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:33100 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33100 J=E9r=F4me Marant writes: > storm@cua.dk (Kim F. Storm) writes: > >> David Kastrup writes: >> >>> I think that any suffix should not be separated by a period, but >>> instead 22.1-pre1 would seem appropriate. >> >> That is a good idea. >> >> Let's look at the possibilities: >> >> >> Type Emacs version With build number >> ---------------------------------------------------------- >> CVS 22.1-dev 22.1-dev.1 >> Pretest 22.1-pre1 22.1-pre1.1 > > What's the rational for not using 22.0.x for development versions? > It would be so much simpler ... Agreed. However, it would be a precursor to "version inflation" since it would mean that the trunk would generally be versioned something.0.x. For example, the internal unicode&multitty-version development would already be at least called 23.0.x. This runs contrary to the trend of conservative version numbers (for example, there does not seem to be _any_ incentive ever to get to 3.something with Linux kernels). However, given that we already are in the twenties (though having started as a teen, skipping childhood), this might be tolerable; it would not appear that we are much in a love affair with small numbers, anyhow. It would be my favorite scheme to start new major version numbers whenever we have ongoing feature development. This would have the advantage that "to be expected for Emacs 27" would usually remain more or less predictable as well as sufficiently rememberable. I can live with other schemes, but I _definitely_ want a scheme where I can tell people a) this feature will be present in version x b) this bug will be fixed in version y and not fall flat on my face by any necessitated intermediate releases. --=20 David Kastrup, Kriemhildstr. 15, 44793 Bochum