Re: Automake 1.6b available and the version numbering issue

[Respond To List Only]

Let me preface this with the comment that, although it may lok like I'm
ranting on some small issue that suddenly pushed me into a fit of rage,
I'm actually sanely trying to raise points that I feel were not
considered dutring the lifespan of automake and other projects.  Please
don't be insulted if I say "total ignorance of downstream"; I mean the
dictionary sense of the words.  I know that other projects cause the
same obstacles, just as many people are involved in Soccer riots.

> >>> "Respond" == Respond To List Only <address@hidden> writes:
> 
>  Respond> ...and how *is* the logic for 1.6b compared to 1.6.3 ?  Is that like
>  Respond> 1.(6.2).0 > 1.6.3 ?
> 
> Here is how this logic is documented in the source.
> (Automake contains a comparison function for its version numbers,
> maybe you could consider reusing it.)
> 
> # A version is a string that looks like
> #   MAJOR.MINOR[.MICRO][ALPHA][-FORK]
> # where
> #   MAJOR, MINOR, and MICRO are digits, ALPHA is a character, and
> # FORK any alphanumeric word.
> # Usually, ALPHA is used to label alpha releases or intermediate snapshots,
> # FORK is used for CVS branches or patched releases, and MICRO is used
> # for bug fixes releases on the MAJOR.MINOR branch.
> #
> # For the purpose of ordering, 1.4 is the same as 1.4.0, but 1.4g is
> # the same as 1.4.99g.  The FORK identifier is ignored in the
> # ordering, except when it looks like -pMINOR[ALPHA]: some versions
> # were labelled like 1.4-p3a, this is the same as an alpha release
> # labelled 1.4.3a.  Yes it's horrible, but Automake did not support
> # two-dot versions in the past.

So what you're saying is "Automake has its own way that is (for complex
reasons) better than a straight logical decimal system.

Sanity-check what you've just copied.  Do you see how it takes 15 lines
to explain?  Does this raise warnings to you?


> (Automake contains a comparison function for its version numbers,
> maybe you could consider reusing it.)

So, one comparison function for Automake, one for OpenSSL, one for the
next program, one for the next program...  Again, creating upstream
problems for downstream users.

> # For the purpose of ordering, 1.4 is the same as 1.4.0, but 1.4g is
> # the same as 1.4.99g.  The FORK identifier is ignored in the

So why not USE 1.4.99.7 ?  Seems much more obvious and intuitive.  Sure,
you might have to sync bugfixes into intermediate snapshots, but users
might actually want bugfixes.

Recall that lexicographically, "4a" and "41" sort in an order that might
not be logical.  Should a hypothetical automake-1.8.4a sort as "more
recent" than automake-1.8.41 ?

How many users can tell you whether 1.4-p3a is newer than 1.4.2 without
looking at the timestamps on the tar.gz files?

Cutting packages, often "-" and "_" are separators for the package
config specs.  a Redhat package of 1.4-p3a probably looks like
automake-1.4-p3a-6.i386.rpm; now, "p3a" is the spec version.  Now, 1.4.2
looks like it is newer than 1.4 (-p3a).


Consider:

        Major.Minor.<intermediate Release>.<bugfix>

I would only like to promote consideration of a simpler system, so that
we can use one comparison function: ">" (and sometimes "<")

Allan