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