Re: Updating release version to 22.1

[David Kastrup <dak@gnu.org>]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>>> So the CVS version will be updated to 22.1.-999, and pretests will
>>> be numbered 22.1.-998 , 22.1.-997 , etc.
>>>
>> The numbering scheme may be geeky, but for all practical purposes
>> it will cause trouble.  Consider this a strong objection.  I would
>> appreciate getting at least the impression that the above reasons
>> have registered before I get overridden.
>
> We have discussed this before, and to the average user, our
> "current" scheme where the cvs version to be released as 21.4 is
> named 21.3.50 is also very confusing.

I don't see how this would justify replacement with a scheme that is
much more confusing.

> I would much rather like to see some descriptive text in there, e.g.
>
>   22.1.DEV
>
>   22.1.PRE-1
>   22.1.PRE-2
>
> etc. when working towards a release 22.1

I think that any suffix should not be separated by a period, but
instead 22.1-pre1 would seem appropriate.  When we are not
particularly passing out something intended to be an approximation to
a release, I'd rather have a version number numerically below the
actual release, something like

21.3-dev20050301

though in our current case I think

22.0-dev20050301

as a precursor to 22.1 would seem a bit more intuitive.  There is a
lot of advice of the sort "will be supported in Emacs 21.4 or later",
and "will be supported in Emacs 22" would give us better possibilities
for being more or less accurate without having to eat our words too
often.

> Subsequent bug fixes could be named
>
>     22.1-1

That is not a good idea since the -%d tags are already used in many
package systems (RPM/Debian) for tagging fixed packages (new configure
options, different package layouts, packaging errors and so on).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum