From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: No calc in pretest? Date: Wed, 03 Jul 2002 00:05:24 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200207022103.g62L32719402@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 1025669209 31912 127.0.0.1 (3 Jul 2002 04:06:49 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 3 Jul 2002 04:06:49 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17PbPl-0008Ib-00 for ; Wed, 03 Jul 2002 06:06:49 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17PbV6-0005z2-00 for ; Wed, 03 Jul 2002 06:12:20 +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 17PbP8-0003zU-00; Wed, 03 Jul 2002 00:06:10 -0400 Original-Received: from 208-59-178-90.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([208.59.178.90] helo=raeburn.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17PbOT-0003xh-00 for ; Wed, 03 Jul 2002 00:05:29 -0400 Original-Received: from kal-el.raeburn.org ([2002:d03b:b25a:1:201:2ff:fe23:e26d]) by raeburn.org (8.11.3/8.11.3) with ESMTP id g6345PW05865; Wed, 3 Jul 2002 00:05:25 -0400 (EDT) Original-Received: from raeburn by kal-el.raeburn.org with local (Exim 3.35 #1 (Debian)) id 17PbOO-000410-00; Wed, 03 Jul 2002 00:05:24 -0400 Original-To: Emacs Devel Mailing List In-Reply-To: <200207022103.g62L32719402@d-ip-129-15-78-125.cs.ou.edu> (Jon Cast's message of "Tue, 02 Jul 2002 16:03:02 -0500") Original-Lines: 125 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1.50 (i686-pc-linux-gnu) 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:5385 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5385 Jon Cast writes: >> Adding cua, tramp, ido, the elisp >> manual, calc, leim and more isn't enough to justify bumping the >> major revision counter ? Why not ? Recently the "major revisions" haven't been about new lisp packages, but more fundamental changes to the core program, and even though I don't make much use of it, I think that MULE support is a much more significant change than adding any of these packages. >> > > What about between v17 and v18 ? >> > I don't think either of those existed. >> I actually don't know but I'd be surprised if you're right. They >> might have never been released, but I expected they existed. > OK, let me expand on my comment: the major version number before 19 > was (IIRC) 1: the version before v19 was 1.18. Uh, no. I just poked around at MIT and found a source tree for Emacs 18.59. But I don't recall much about versions before 18. X10 and VMS support appear to be a couple of the big new features it added; remote file access, pop-up menus and a bunch of other things were added too. X11 support was added in 18.50. Earlier versions are described in etc/ONEWS.* in the current tree. Version 13 was preceded by 1.12. The first change listed for v13 is: * There is a new version numbering scheme. What used to be the first version number, which was 1, has been discarded since it does not seem that I need three levels of version number. However, a new third version number has been added to represent changes by user sites. This number will always be zero in Emacs when I distribute it; it will be incremented each time Emacs is built at another site. There's also a reference to version "13.9". Some other interesting tidbits: Emacs 16 reduced redisplay during incremental searching on slow terminals by displaying only a few lines. I think I remember when that change came along, so I'm pretty sure that at least the more adventurous of us were using it in my group at MIT by then... Emacs 15 added Sun 68k support, lisp stack overflow checks, texinfo. Emacs 1.12 introduced support for "meta" characters. Emacs 13 introduced the ?\M-x and ?\C-x syntax for using meta and control characters in lisp. Emacs 1.10 on VAX 4.2 BSD was 530K, after dumping. Today it's what, nearly 7M on x86? Emacs 1.9 added support for "+" and "?" in regular expressions. Emacs 1.7 changes say: It's Beat CCA Week. CCA had a version of Emacs too. It was a little more friendly in some ways, perhaps, but had some serious problems, and GNU Emacs quickly pulled ahead. MIT's Project Athena (which provided some of the software for students in the mid 80s) suffered with CCA Emacs for a while -- at least, the less adventurous people did. They're an interesting read. Just in case anyone was thinking that Emacs sprang fully-formed from RMS's forehead. :-) > 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. :-) It's multiple numbers, each possibly with multiple digits, separated by dots; that's how it has to be sorted. 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. 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. Ken