Hi Respond, >>> "Respond" == Respond To List Only <[EMAIL PROTECTED]> writes:
Respond> Let me preface this with the comment that, although it Respond> may lok like I'm ranting on some small issue that Respond> suddenly pushed me into a fit of rage, I'm actually Respond> sanely trying to raise points that I feel were not Respond> considered dutring the lifespan of automake and other Respond> projects. (FWIW past discussions about version numbering can be found in the archive of the lists.) [...] Respond> Sanity-check what you've just copied. Do you see how Respond> it takes 15 lines to explain? Does this raise Respond> warnings to you? Good point. Let's not make this explanation longer by supporting yet another numbering scheme. [...] >> # 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 Respond> So why not USE 1.4.99.7 ? Historical practice I'd say. For many years, Automake has used the same numbering scheme as many other GNU packages: N.M for releases, N.Mx for snapshots But when the need for bug fix releases occured, it was extended to follow the same practice as Libtool (IIRC): N.M for major releases N.Mx for snapshots between major releases N.M.O for bug fix releases N.M.Ox for snapshots between bug fix releases Everything that ends with a letter is *not* a release. It's an intermediate snapshot, a development version, a pre-release -- call it how you like, but it's not an official release. Releases uses only numbers like it seems you prefer. (The N.M-pO versions were an accident, we don't use these today.) [...] Respond> Recall that lexicographically, "4a" and "41" sort in Respond> an order that might not be logical. Peanut. Even `ls -v' is able to sort that. I insist. Let's not make a montain out of a molehill. There are existing tools (like GNU ls, or Debian's dpkg) that contains comparison functions which are able to cope with most version numbering schemes. Reuse this work! This way it will solve your problem, not only for Automake, but also for many other tools at the same time. [...] -- Alexandre Duret-Lutz