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: No calc in pretest? Date: 05 Jul 2002 22:55:01 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <5xsn2xevyy.fsf@kfs2.cua.dk> References: <200207042331.g64NVJ726720@d-ip-129-15-78-125.cs.ou.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1025899018 29842 127.0.0.1 (5 Jul 2002 19:56:58 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 5 Jul 2002 19:56:58 +0000 (UTC) Cc: rms@gnu.org, miles@gnu.org, pot@gnu.org, eliz@is.elta.co.il, burton@openprivacy.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17QZCM-0007lD-00 for ; Fri, 05 Jul 2002 21:56:58 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17QZIz-0008Ld-00 for ; Fri, 05 Jul 2002 22:03:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17QZCU-00052c-00; Fri, 05 Jul 2002 15:57:06 -0400 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17QZAB-0004tM-00; Fri, 05 Jul 2002 15:54:43 -0400 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id F097E7C016; Fri, 5 Jul 2002 19:54:24 +0000 (GMT) Original-To: Jon Cast In-Reply-To: <200207042331.g64NVJ726720@d-ip-129-15-78-125.cs.ou.edu> Original-Lines: 45 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5520 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5520 Jon Cast writes: > storm@cua.dk (Kim F. Storm) wrote: > > > The CVS version and the pretest should use the same minor number as > > the next release. That's the only consistent numbering scheme. > > I assume by ``consistent'' you mean ``roughly indicating the feature > set by the major/minor version number''? In other words, interpret a > major/minor pair as indicating a feature set, and assign each release > the major/minor pair indicating its feature set most closely. With > that meaning, I think a coherent argument could be made that we should > be conservative, and assign each release the largest major/minor pair > indicating a feature set /completely containing/ the feature set of > the release. That would dictate giving CVS versions the minor number > of the preceding release. I simply don't follow... The CVS version is working *towards* the next release, so it should have the version number of the release it is going to be eventually. > > For a concrete example, suppose in Emacs 21.5 customize options and > groups get a new :file keyword giving a file name to store the > option's setting in. (I.e., Tramp could add :file ".tramp" to the > tramp defgroup, and Tramp's settings would be stored in ~/.tramp.) > Suppose this option were added on 2002 October 23. Now, assume > someone is running CVS Emacs as of 2002 October 22 (version > 21.5.-99.3). He installs a third-party package you've released, which > wants to know if :file is supported, and use it if it is. So, your > package tests emacs-minor-version, and determines it is 5. > Conclusion: customize supports :file. Reality: customize doesn't > support :file. Not good. That's not a valid argument IMHO! People using the CVS emacs version should be expecting that things will break from time to time if they don't update regularly. We cannot and should not be backwards compatible with "yesterday's CVS", and there is no reason to be able to differentiate! -- Kim F. Storm http://www.cua.dk