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 15:54:58 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200207032054.g63KswD22435@d-ip-129-15-78-125.cs.ou.edu> References: NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1025729807 22943 127.0.0.1 (3 Jul 2002 20:56:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 3 Jul 2002 20:56:47 +0000 (UTC) Cc: 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 17PrB9-0005xw-00 for ; Wed, 03 Jul 2002 22:56:47 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17PrGo-0003bx-00 for ; Wed, 03 Jul 2002 23:02:39 +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 17PrBV-0005ys-00; Wed, 03 Jul 2002 16:57:09 -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 17Pr9e-0005nP-00 for ; Wed, 03 Jul 2002 16:55:14 -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 g63KswD22435; Wed, 3 Jul 2002 15:54:59 -0500 X-Authentication-Warning: d-ip-129-15-78-125.cs.ou.edu: jcast owned process doing -bs Original-To: Ken Raeburn In-Reply-To: Message from Ken Raeburn of "Wed, 03 Jul 2002 00:05:24 EDT." 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:5414 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5414 Ken Raeburn wrote: Btw., thanks for all this. I apologize for saying 18 was the first non-1.x release (whoops), but I stand firm in my position major number changes have always meant significant changes internally (although clearly not the other way around). So, we should /not/ use x.0 to indicate `release from CVS head'. > > What trouble? The trouble of converting to a three-element system > > (i.e., using fully general lexical ordering rather than un-rolling > > the loops), or the trouble of changing things if what we thought > > was x.y turns out to be (x+1).1? Nobody's asking you to take any > > trouble about the first case, and I doubt the second case will be > > important enough to bother you. > Lexical ordering doesn't work on this style of version number. By > general lexical ordering, 22.10.1 comes before 22.9.1, because "1" > comes before "9". And the immediate successor to "22.9" is "22.:" > if you go by the ASCII chart. :-) Sorry, I meant lexical ordering in the mathematical sense: i.e., parse 21.4.0.50.yyyymmdd.z as (21 4 0 50 yyyymmdd) and then define ordering as (defun lte (xn ys) (or (= xn nil) (and (listp xn) (listp ys) (or (< (car xn) (car ys)) (and (= (car xn) (car ys)) (lte (cdr xn) (cdr ys))))))) (I think; my lisp is a little weak.) > It's multiple numbers, each possibly with multiple digits, separated > by dots; that's how it has to be sorted. Right. > If we want lexical sorting to work, we could require two- or > three-digit fields with leading zeros, and no overflow allowed -- > i.e., no ".100" after ".99" even if more pretests are needed, but > ".100" after ".099" would be okay. We could, but I'd rather not. > My two cents on the issue: > I like the "major.minor.bugfix[.yyyymmdd]" proposal. > "Real" releases with new development work and bugfix releases can be > distinguished at a glance, and for the most part we can predict what > the next version of each type would be called. We don't have to > tell people, "I just put this change in on the trunk, it'll be in > release 21 point ... uh ... lemme think, 'nother bugfix release is > in the works, that'll be 21.17, so the next release off the trunk is > 21.18. Yeah, it'll be in 21.18. Or not, if things change." With > the extra field for bugfixes, we can say "21.18" and mean it -- > unless there's no new release before version 22, but someone who was > told something would be in 21.18 will probably figure it out easily. > Leaving off the bugfix number for the initial release (i.e., "21.4" > to be followed by "21.4.1" with bugfixes) leads to confusions when > the build process tacks on another number indicating the local build > count. So, third build of 21.4 would be 21.4.3, but the first build > of the bugfix release following it would be 21.4.1.1; no, that's no > good. And the datestamp would just magnify that problem. But > datestamps are much larger than any local build count is going to > be, so the version ordering is still clear when datestamps are added > (if you do your sorting correctly). > Starting at .1 instead of .0 makes sense, so that each prerelease > can have the .90 or whatever and still use the new version at the > higher level, i.e., 22.0.90 is clearly in the v22 line *and* comes > before 22.1, the first real release in that line. I agree; it also means loadup.el won't cause any confusion by declaring 22 22.1 and 22.1 22.1.1 :) > Ken Jon Cast