Re: Updating release version to 22.1

[David Kastrup]

Jérôme Marant <address@hidden> writes:

> address@hidden (Kim F. Storm) writes:
>
>> David Kastrup <address@hidden> writes:
>>
>>> I think that any suffix should not be separated by a period, but
>>> instead 22.1-pre1 would seem appropriate.
>>
>> That is a good idea.
>>
>> Let's look at the possibilities:
>>
>>
>> Type             Emacs version             With build number
>> ----------------------------------------------------------
>> CVS              22.1-dev                  22.1-dev.1
>> Pretest          22.1-pre1                 22.1-pre1.1
>
> What's the rational for not using 22.0.x for development versions?
> It would be so much simpler ...

Agreed.  However, it would be a precursor to "version inflation" since
it would mean that the trunk would generally be versioned
something.0.x.  For example, the internal unicode&multitty-version
development would already be at least called 23.0.x.  This runs
contrary to the trend of conservative version numbers (for example,
there does not seem to be _any_ incentive ever to get to 3.something
with Linux kernels).  However, given that we already are in the
twenties (though having started as a teen, skipping childhood), this
might be tolerable; it would not appear that we are much in a love
affair with small numbers, anyhow.

It would be my favorite scheme to start new major version numbers
whenever we have ongoing feature development.  This would have the
advantage that "to be expected for Emacs 27" would usually remain more
or less predictable as well as sufficiently rememberable.

I can live with other schemes, but I _definitely_ want a scheme where
I can tell people

a) this feature will be present in version x
b) this bug will be fixed in version y

and not fall flat on my face by any necessitated intermediate
releases.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum