From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.] Date: Thu, 30 Sep 2004 11:36:33 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <1096291271.415813c757a26@imp6-q.free.fr> <20040927134714.GA20012@fencepost> <87hdphx91c.fsf@trouble.defaultvalue.org> <87655wswkv.fsf@trouble.defaultvalue.org> <1096489325.415b196d95987@imp3-q.free.fr> <200409300053.i8U0rWh20758@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1096539968 1120 80.91.229.6 (30 Sep 2004 10:26:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 30 Sep 2004 10:26:08 +0000 (UTC) Cc: jerome.marant@free.fr, rms@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, rlb@defaultvalue.org, miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 30 12:25:48 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 1CCy8C-0002PL-00 for ; Thu, 30 Sep 2004 12:25:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CCyEZ-0000BC-Vn for ged-emacs-devel@m.gmane.org; Thu, 30 Sep 2004 06:32:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CCyEP-0000B7-0z for emacs-devel@gnu.org; Thu, 30 Sep 2004 06:32:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CCyEN-0000Au-Of for emacs-devel@gnu.org; Thu, 30 Sep 2004 06:32:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CCyEM-0000Ar-PL for emacs-devel@gnu.org; Thu, 30 Sep 2004 06:32:11 -0400 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.34) id 1CCy7i-0003iQ-9S for emacs-devel@gnu.org; Thu, 30 Sep 2004 06:25:20 -0400 Original-Received: (qmail 20856 invoked from network); 30 Sep 2004 09:36:32 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 30 Sep 2004 09:36:32 -0000 Original-To: Luc Teirlinck In-Reply-To: <200409300053.i8U0rWh20758@raven.dms.auburn.edu> (Luc Teirlinck's message of "Wed, 29 Sep 2004 19:53:32 -0500 (CDT)") User-Agent: Gnus/5.1006 (Gnus v5.10.6) 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27696 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27696 Luc Teirlinck writes: > Jerome Marant wrote: > > Selon Rob Browning : > > > 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. > > It brings some consistency to version numbering at least. If noone > objects (Stefan won't :-), we'll adopt this scheme. > > After grepping for `emacs-version', it appears that changing the > current convention would require checking a surprisingly *huge* amount > of code. A non-trivial amount of code will probably have to be > rewritten. version.el definitely would have to be rewritten. I don't see why. CVS emacs currently has emacs-version 21.3.50.12 or similar, so what need changing? > This is > a small file. But it would then in turn force rewriting all kind of > other stuff, spread all over the place. Many third party packages may > get broken, as they tend to check for emacs-version a lot and rely on > the current conventions. If code usese emacs-version to check for what features are available then a) that code is broken in the first place if it cannot handle the CVS emacs version string format, and b) such code should only look at the X and Y components of the version number. The rationale for b) is that the Z component differentiates BUG FIX releases, so from 3rd party packages point of view, X.Y, X.Y.0 and X.Y.7 are to be considered equivalent functionality-wise. So I think X.Y.Z would work fine. BTW, what is currently really broken in CVS emacs is that emacs-minor-version is 3 -- it should be 4. Since we use X.Y.50 and X.Y.90 for cvs and pretest versions for X.(Y+1), a better approach would be: (defconst emacs-minor-version (if (and (string-match "^[0-9]+\\.\\([0-9]+\\)\\.\\([0-9]+\\)" emacs-version) (>= (string-to-int (match-string 2 emacs-version)) 50)) (1+ (string-to-int (match-string 1 emacs-version))) (string-to-int (match-string 1 emacs-version))) "Minor version number of this version of Emacs. This variable first existed in version 19.23.") -- Kim F. Storm http://www.cua.dk