Re: Bump mainline version number

[Zack Weinberg <zack at codesourcery dot com>]

Nick Clifton <nickc@redhat.com> writes:

> Hi Zack,
>
>> http://www.panix.com/~zackw/exbib/2002/June/20#1445
>> http://www.panix.com/~zackw/exbib/2002/June/30#1150
>
> Ok, so you think that the branch that is about to be released ought to
> be version 2.14.0 correct ?

Or 2.14 - same thing.

> And that the current CVS sources should not have a version number at
> all, or if they do, it ought to be something like "2.15.0
> <today's-date>".  Is that right ?

It should be "2.15.0 prerelease <datestamp>".  Or "experimental" or
"development" or whatever.

The 'development sources don't have a version number at all' stuff is
mainly talking about the Linux-and-a-few-others practice of using odd
minor versions to indicate development source, which I think is bad
practice.  

> Currently the CVS sources produce a version string of "2.15.90
> 20030506".  I believe that the origin of the .90 value was the
> assumption that the patch level of a released branch would never
> reach 90, so it was safe to use that in the development sources.  ie
> avoiding any possible conflict with the to-be-released-in-the-future
> 2.15 branch and any of its patch releases.

HJ's original objection, I *think*, was that - 2.14(.0) having just
been released - keeping with the existing scheme would mean that the
trunk should have version number 2.14.90.

As it happens I think the .90 suffix is a bad idea - not because
there's any real risk of the 2.14 release series catching up with it,
but because it "contributes to the pernicious misapprehension that
version numbers are decimal fractions."  .90 sounds like you're
counting up to 1.00.  People really *have* had to do more than ten
prereleases each with their own patchlevel number, and had users be
confused by "x.y.100".  Using date stamps to indicate relative age of
prereleases avoids this problem.

zw