The Core Problem with Parrot Version Numbers
Geoffrey Broadwell
geoff at broadwell.org
Fri Feb 20 18:41:05 UTC 2009
On Fri, 2009-02-20 at 10:32 -0800, chromatic wrote:
> If people are going to read that information into our version numbers, our
> version numbers should reflect that.
>
> To make the jump from 2.0 to 2.5 in six months work, we have to say, *right
> now*, that one of the releases will contain only "minor improvements",
> whatever that means. Is anyone here willing to predict what we'll have ready
> with that degree of confidence a year in advance? Numerically, this scheme
> *does not work*. It does not fit how we work, and it does not reflect how we
> release software and the promises we make about future versions of that
> software.
Hear, hear!
> If we absolutely *must* have real numbers as version numbers, I hereby donate
> a nickel to the Parrot foundation so that we can buy more real numbers and
> bump up the major version every six months, thereby solving the "What's the
> deprecation policy?" question and the "Should I upgrade?" question and the
> "There aren't enough real numbers between 0 and 5!" problem.
I'll match that donation.
-'f
More information about the parrot-dev
mailing list