Re: Automake release

[Bob Proulx]

Random thoughts on version numbers...

> to do this with automake since I've been saying for a long time "1.5
> will do this", "1.5 will do that".  Bleah, my bad.

> Agreed.  Buuut... 1.4a-p1 seems wrong if HEAD is at 1.4c.  Worse, releasing 
> 1.4b-p1 sounds like it is related to 1.4b.  I still don't like it, and won't 
> adopt it for libtool or m4.

> In all this is an ugly situation.  I'm thinking of hacking automake to
> recognize that `1.4-p<N>' is between 1.4 and 1.5 (so that
> AUTOMAKE_OPTIONS=1.4-p1 will work ok when 1.5 is used).

> In gnits there are only two numbers.  The third one, if it exists,
> indicates an alpha release.

If the version is 1.4-p1 then will an RPM package version be
automake-1.4-p1-1.arch.rpm?  Oops.  That is too many dashes.  Unless
the release of the package is p1, which would work exactly once.  But
if you need to do a second release that would be p2.  Oops that does
not work.  Using a '-' in the name is bad for people trying to make an
RPM package of the code.  The packager is forced to coerce the name
into something without a dash and then it does not match.

IMNHO version numbers should always be whole counting numbers.  I
think everyone is moving that direction.  I understand that many
projects have been in process for literally years and have legacy to
maintain.  With that method automated tools can understand which
version is later than another version.  Otherwise, even a human can
get confused.

[Soapbox Follows]

A terrible situation exists with some packages.  Some people use a
letter to mean a patch on top of the version.  Others use it to mean a
test beta release candidate for that version.  BIND comes to mind as
an example.  Which means sometimes it is before and sometimes it is
after and you just have to know.  I would like to pass a law against
anything that immoral.

There should be no letters in a version.  Is 8.2.3p4 a test release
for an upcoming 8.2.3 or a patch on top of 8.2.3?  It turns out this
is a test release for an upcoming 8.2.3.  But fileutils 4.0e is a test
beta release for 4.1.  Eventually all letters were consumed and 4.0.45
was the last beta release before the release of 4.1.  It would have
been more consistent to use numbers all along since it is unlikely to
run out of those.

Another problem is that some people think versions numbers are
floating point numbers.  I don't think that is a defendable position.
Especially when you have test betas with a second dot.  What floating
point number is 1.2.3?  But it means that if you release 2.50 people
will constantly get that version confused with version 2.5 which is
likely a much older version.  But if it is a floating point number
then all zeros on the end could be dropped.  Therefore I advocate
avoiding releasing versions ending in zero.  It only confuses people.
Is version 1.10 the same as version 1.1?  Probably not.  Better to
avoid 1.10 and release it as 1.11 so that there is no doubt.

Floating point numbers in general are a problem.  Sometimes people try
to reserve space with zeros.  1.02 is a bad version number.  Is that
the same as 1.2?  Did they really mean 1.0.2?  Also 5.005_03 is a
terrible way to version.  At least they are going with 5.6.1 for later
releases.  Is netscape-4.61 newer or older than netscape-4.7?  Of
course it is older just because we know it is but how do you code the
algorithm which always gets it right?

Version numbers should be whole counting numbers.  Linux 2.2.18 is a
fine version number.  Later than 2.2.14 and earlier than 2.4.4.  No
confusion there.

Bob