From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.devel Subject: Re: DONE: Updating release version to 22.1 Date: Wed, 09 Feb 2005 11:39:12 -0600 Message-ID: <87is51bpkv.fsf@trouble.defaultvalue.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1107970993 4998 80.91.229.2 (9 Feb 2005 17:43:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 9 Feb 2005 17:43:13 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 09 18:43:12 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Cyvrm-0004OC-EP for ged-emacs-devel@m.gmane.org; Wed, 09 Feb 2005 18:43:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cyw6L-0002hs-P6 for ged-emacs-devel@m.gmane.org; Wed, 09 Feb 2005 12:58:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cyw5I-0002Pn-W1 for emacs-devel@gnu.org; Wed, 09 Feb 2005 12:57:05 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cyw59-0002Iw-0O for emacs-devel@gnu.org; Wed, 09 Feb 2005 12:56:57 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cyw56-0002Hs-Dg for emacs-devel@gnu.org; Wed, 09 Feb 2005 12:56:52 -0500 Original-Received: from [66.93.216.237] (helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cyvo2-0005Xw-Os for emacs-devel@gnu.org; Wed, 09 Feb 2005 12:39:15 -0500 Original-Received: from trouble.defaultvalue.org (omen.defaultvalue.org [192.168.1.1]) by defaultvalue.org (Postfix) with ESMTP id CDA0E3FE4; Wed, 9 Feb 2005 11:39:12 -0600 (CST) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id 827CE3C101A; Wed, 9 Feb 2005 11:39:12 -0600 (CST) Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Wed, 09 Feb 2005 17:08:11 +0100") User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (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:33147 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33147 storm@cua.dk (Kim F. Storm) writes: > I have installed these changes: > > Change release version from 21.4 to 22.1 throughout. > > Change development version from 21.3.50 to 22.0.50. As long as the convention that X.0.Y is a development pre-release is well-publicized, this seems like a reasonable convention. With respect to some of the other comments in this thread: - It would be perfectly fine as far as Debian' is concerned for you to use dashes in your version names, i.e. 22.0-pre22.1-3. (http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version) Debian only presumes that its "revision" is what comes after the final dash (if any). (Using something like a 22.0 prefix would also mean that this version will still sort reasonably when 22.1 is finally released. Although Debian can always work around upstream numbering inconsistencies. That's what version epochs are for.) - Given the 22.0.50 approach above, what's the plan for *stable* pre-release versions? Say that 22.1 is the current release, and you need to make some tricky change for 22.3, tricky enough that you want to make an official pre-release for testing. (Perhaps that's not a viable scenario.) - I wonder if it might be helpful to separate out the "pre-release" status and make it official, i.e. have emacs-major-version, emacs-minor-version, *and* emacs-prerelease. The latter might be an integer for pre-releases and nil otherwise. This would allow you to programatically decide when to expose/hide the pre-release status. i.e. in display strings, you might want to show it, but most code would only want to look at major/minor. - It seems like the name used for a particular release might best depend on the context. Given the variable separation above, you might name the file emacs-22.1-pre4.tar.gz, have emacs-version report "GNU Emacs 22.1 (prerelease 4) ...", and have emacs-major, minor, and prerelease set to 22, 1, and 4 respectively. Then as mentioned, most important code would be acting on the values planned for the official release. Only code that needed to check for emacs-prerelease would, and the only real difference between the final (tested) pre-release and the official release would be (setq emacs-prerelease nil). - The now-defunct idea of naming the next major release 21.4 might have caused some problems for Debian and perhaps other distributions. This is because Debian allows people to install and run older "major" versions of emacs. Right now we have emacs20 and emacs21 (though emacs20 is about to be dropped), and the current system expects that installing a new version of emacsX won't break or change much. If 21.4 had been a major departue from 21.3, then we would have had to re-work our packaging so that instead of an emacs21 package, we'd have emacs21.4. We would also have had to change some internals. For example, the value of debian-emacs-flavor would have to be emacs21.4 rather than emacs21, and any add-on package's code that presumed that flavors wouldn't have a "." in them would be in trouble. This is probably not a huge concern for you, but I thought I'd mention it. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4