Hi,
this is a rant about Catalyst’s version numbers.
The current scheme is a ridiculous, never-ending pain in the rear.
It’s been 5.900xx for 2 years, before that it was 5.800xx for over
2 years, following on 5.70xx for 2 years, following 5.6xx for only
about a year, to which it got from 3.00 in the span of a single year.
Even the maintainers can’t keep it straight! (There have repeatedly
been releases with too few fractional digits.)
It is my understanding that at some point in history – or several,
now that I look at the Changelog –, the version number got screwed
up, and since downstream distro packaging sanity requires never again
making the version number shorter as a string, it grew and grew and
grew… and the pace of version number increases slowed and slowed and
slowed.
Can’t this be fixed by bumping the major version to 6 and dumping
those two stupid extra zeroes? The Catamoose release would have
been a natural point at which to do this – alas.
But imagine if 5.8 had landed as 6.000. Then we’d’ve had
6.100 instead of 5.9000 (yes, only had 4 fractional digits)
6.200 instead of 5.90020 (now 5 frac’n digits…)
6.300 instead of 5.90030
6.400 instead of 5.90040
6.500 instead of 5.90050
Look at that: 6.100, 6.200, 6.300, 6.400, 6.500.
(I picked 1 digit minor version and 2 digits for point releases,
since that appears to be roughly how the sequence of releases so
far have played out. Coincidentally (except, if you think about
it, not so much) this is how I personally have come to version
all my stuff too.)
Isn’t that so much nicer to look at than 5.9000, 5.90020, 5.90030,
5.90040, 5.90050? It would also be so much easier to have a feel of
roughly how old any given version is, just by the version number.
But OK, it didn’t happen that way.
Note this would have ended up forcing a new major version in much
less time than the current scheme will, but if I look at the length
of the time frames, it would still take the better part of a decade.
That seems entirely reasonable.
Catalyst raced from 3.00 to 5.6 in only 10 months – then 8 years to
crawl up to 5.90051. That seems anything but reasonable. Worse, if
those two zeroes in there are made use of then it might *never* get
beyond 5.9 – and imagine *that* insanity. 5.90214? 5.92041? Hoo boy.
(Would it even be unreasonable to whirr up the major versions faster
than I have proposed here?)
How about doing a Linus and putting an end to version number madness
by simply declaring the next version to be a new major release? If we
didn’t have sanity so far, at least we can have it from here on out.
It’s never too late to fix an ongoing problem.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
this is a rant about Catalyst’s version numbers.
The current scheme is a ridiculous, never-ending pain in the rear.
It’s been 5.900xx for 2 years, before that it was 5.800xx for over
2 years, following on 5.70xx for 2 years, following 5.6xx for only
about a year, to which it got from 3.00 in the span of a single year.
Even the maintainers can’t keep it straight! (There have repeatedly
been releases with too few fractional digits.)
It is my understanding that at some point in history – or several,
now that I look at the Changelog –, the version number got screwed
up, and since downstream distro packaging sanity requires never again
making the version number shorter as a string, it grew and grew and
grew… and the pace of version number increases slowed and slowed and
slowed.
Can’t this be fixed by bumping the major version to 6 and dumping
those two stupid extra zeroes? The Catamoose release would have
been a natural point at which to do this – alas.
But imagine if 5.8 had landed as 6.000. Then we’d’ve had
6.100 instead of 5.9000 (yes, only had 4 fractional digits)
6.200 instead of 5.90020 (now 5 frac’n digits…)
6.300 instead of 5.90030
6.400 instead of 5.90040
6.500 instead of 5.90050
Look at that: 6.100, 6.200, 6.300, 6.400, 6.500.
(I picked 1 digit minor version and 2 digits for point releases,
since that appears to be roughly how the sequence of releases so
far have played out. Coincidentally (except, if you think about
it, not so much) this is how I personally have come to version
all my stuff too.)
Isn’t that so much nicer to look at than 5.9000, 5.90020, 5.90030,
5.90040, 5.90050? It would also be so much easier to have a feel of
roughly how old any given version is, just by the version number.
But OK, it didn’t happen that way.
Note this would have ended up forcing a new major version in much
less time than the current scheme will, but if I look at the length
of the time frames, it would still take the better part of a decade.
That seems entirely reasonable.
Catalyst raced from 3.00 to 5.6 in only 10 months – then 8 years to
crawl up to 5.90051. That seems anything but reasonable. Worse, if
those two zeroes in there are made use of then it might *never* get
beyond 5.9 – and imagine *that* insanity. 5.90214? 5.92041? Hoo boy.
(Would it even be unreasonable to whirr up the major versions faster
than I have proposed here?)
How about doing a Linus and putting an end to version number madness
by simply declaring the next version to be a new major release? If we
didn’t have sanity so far, at least we can have it from here on out.
It’s never too late to fix an ongoing problem.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev