Re: No calc in pretest?

[Stefan Monnier]

> > We could simply decide that RC versions will be 21.1, 21.2, 21.3,
> > 21.4 and the next trunk version will be 22.1 (at which point it will
> > be on its own branch for 22.2, 22.3, 22.4, ...).
> 
> This is, as many others have pointed out, a /bad/ idea.  The only
> reason for having multiple version numbers at all, rather than number
> 1, 2, 3, 4, ..., is to inform users of the gravity of changes.  Making
> a major release every time a release from trunk is made will destroy
> that information.

As I said, I don't really buy that argument.  We'd still have this
info since 22.2 would be a bugfix release (i.e. a minor change) over
22.1.  We just wouldn't be able to differentiate between "major"
and "really major", but as I pointed out, this has already been the case
in the past, if you look at how the 19.x versions evolved.  There
was no easy way to tell if a new version was just a bugfix, a minor
improvement or a major step forward.

> Anyway, loadup.el should work without modification (or with only
> slight modifications) in my scheme (it DTRT with CVS versions, which
> have three element version numbers :).  And ISTR that CVS bug reports
> go to a different address than pre-test bug reports, so emacsbug.el
> probably needs to be fixed anyway.  So, I don't see any technical
> reason not to go with three element version number for bug fix
> releases, and a very good psychological/sociological reason to switch
> to them.

For the record, I don't have any objection to using 3-part revisions.
I just find that keeping the same 2-part revisions but just
bumping the first number more often is simpler.


        Stefan