From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Jon Cast Newsgroups: gmane.emacs.devel Subject: Re: No calc in pretest? Date: Wed, 03 Jul 2002 16:27:38 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200207032127.g63LRcF22542@d-ip-129-15-78-125.cs.ou.edu> References: <5xk7odas1q.fsf@kfs2.cua.dk> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1025731803 27087 127.0.0.1 (3 Jul 2002 21:30:03 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 3 Jul 2002 21:30:03 +0000 (UTC) Cc: Francesco Potorti` , Eli Zaretskii , burton@openprivacy.org, Emacs Devel Mailing List Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17PrhK-00072m-00 for ; Wed, 03 Jul 2002 23:30:02 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17Prn0-0004Ig-00 for ; Wed, 03 Jul 2002 23:35:54 +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 17PrhT-0000Ca-00; Wed, 03 Jul 2002 17:30:11 -0400 Original-Received: from d-ip-129-15-78-125.cs.ou.edu ([129.15.78.125]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17PrfF-0008T4-00; Wed, 03 Jul 2002 17:27:53 -0400 Original-Received: from ou.edu (jcast@localhost) by d-ip-129-15-78-125.cs.ou.edu (8.11.6/8.11.6) with ESMTP id g63LRcF22542; Wed, 3 Jul 2002 16:27:38 -0500 X-Authentication-Warning: d-ip-129-15-78-125.cs.ou.edu: jcast owned process doing -bs Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: Message from storm@cua.dk (Kim F. Storm) of "Wed, 03 Jul 2002 14:56:33 +0200." <5xk7odas1q.fsf@kfs2.cua.dk> 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:5419 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5419 storm@cua.dk (Kim F. Storm) wrote: > I don't see any reason to separate CVS snapshot versions from > pretest versions. emacsbug.el should (probably) send bug reports > for either type of build to the emacs-pretest-bug address. I take it by ``snapshot'' you mean a tarball containing the state of CVS on a particular date, right? > So I suggest the following: > 21.5.0.0 -- Direct build from CVS head. > 21.5.0.yyyymmdd -- Snapshot or pretest from CVS head. > 21.5.1 -- Initial release from CVS head. > 21.5.x -- Bug-fix release (x > 1) Why differentiate CVS from snapshots? I'd assume the current date could be written into CVS by a cron script on subversions or elsewhere, and that would also keep the ordering correct---with your scheme, my CVS checkout made today (version 21.5.0.0) looks older than the next guys CVS snapshot release three weeks ago (version 21.5.0.20020803). That's not good. It's not catastrophic, but it's not good. > The build number is appended to these numbers, so we end up with the > users seeing numbers like this where y is typically 1. > 21.5.0.0.y > 21.5.0.20020703.y > 21.5.1.y > 21.5.x.y > For the release build numbers, this looks ok. > For the CVS builds, this is also ok, as it clearly differentiates > these builds from builds based on official releases. I agree this looks good. I'm not convinced CVS bugs go to the emacs-pretest-bug address, but I think the resulting schemes are sufficiently similar we can go with your scheme unless we get a more definitive answer. > > The reason for having separate version numbers for CVS > > (x.y.0.50.yyyymmdd and x.y.0.9z) is that I think emacsbug.el needs > > to be able to differentiate them, and that seems easiest to > > implement > No, emacsbug counts the number of `.'s in the version string, and if > there is more than 2 (currently), it supposes it is a pretest. I know what emacsbug does. What I meant was, checking a particular number seems easiest to implement, and (nth 4 (parse-version emacs-version)) (where `parse-version' returns a list of the components of its argument) seemed as good a number as any. > With my scheme, the test would simply be > (let ((pretest-p (= emacs-minor-minor-version 0))) > ...) What about bug-fix pretests? Those probably shouldn't have emacs-micro-version = 0 --- that destroys the lexical ordering on versions again. (Please don't tell me you'd object to calling 21.5.(x+1)'s pretest 21.5.x.90 --- micro numbers have infinitesimal information for programs anyway.) > of course, I'm assuming we have a variable containing the > minor-minor number (can someone come up with a better term?) Micro number sounds good to me. > -- > Kim F. Storm http://www.cua.dk