On Sep-21, Gerrit P. Haase wrote: > Hallo again, > > >>>http://cpan.perl.org/authors/id/S/SF/SFINK/parrot-0.0.11.1.tar.gz > > >> And all we need now is a 0.0.11.2, with patches to allow four-element > >> version numbers... > > [...] > > Ouch, better take this: > $ diff -urd parrot-0.0.11.1/VERSION~ parrot-0.0.11.1/VERSION > --- parrot-0.0.11.1/VERSION~ 2003-09-21 13:17:42.490672000 +0200 > +++ parrot-0.0.11.1/VERSION 2003-09-21 13:16:56.794964800 +0200 > @@ -1 +1 @@ > -0.0.11.1 > +0.0.11
Heh. I just went down the same road, and came to the same conclusion. For the casual observers: The problem is that those patches to allow four-element version numbers are decidedly nontrivial. The immediate failure is lib/Parrot/BuildUtil, which aborts Configure.pl because it insists on seeing 3-part version numbers. The next failure is ops2c.pl, which uses Parrot::OpsFile to tell it the decomposed parts of the version string -- major, minor, patchlevel. And it appears that those three values are stored in the bytecode, and I'm guessing that the value 1.2 will not fit very comfortably into an integer field. So even if we wanted to allow 4-digit version strings, it's too much of a change to make while packaging up a release, so it's much easier to just say the version is 0.0.11 and be done with it. Or if you really want proper versioning, 0.0.12. If we got out of this silly "version 0.0" hole, then we wouldn't need to be so hung up about the stupid patch level. A parrot-0.0.11.2.tar.gz is now staggering drunkenly towards CPAN, using VERSION=0.0.11. I even tested it this time. If people want 0.0.12 instead, I can do that too. Argh.
