Re: No calc in pretest?

[Jon Cast]

Ken Raeburn <address@hidden> wrote:
<snip, including some fascinating Emacs history>

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