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 -- [email protected] _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
