Re: No calc in pretest?

[Ken Raeburn <raeburn@raeburn.org>]

Jon Cast <jcast@ou.edu> 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