The Core Problem with Parrot Version Numbers

[Jerome Quelin]

On 09/02/20 10:32 -0800, chromatic wrote:
> 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.
> 
> 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 think this is the best scheme that we can come up with.

not that i don't like the name-as-version release, but i guess all the
packagers of linux distribution will *hate* us for that. because
while number-based versions are monotone, i don't know if the various
rpm, deb, emerge, etc will know that cockatoo comes after budgie.

my 2 cents,
jérôme 
-- 
jquelin at gmail.com