On Thu, Feb 19, 2009 at 3:56 PM, chromatic <[email protected]> wrote: > That's why I like the date-based scheme. > > Alternately, we could skip all of the debates about what's major and minor and > how many real numbers there are between 1.0 and 1.5 or 1.5 and 2.0 and say: > > July 1.5(.0) > 1.5.1 > 1.5.2 > 1.5.3 > 1.5.4 > 1.5.5 > January 2.0(.0) > > That satisfies the property that version numbers should increase and it gives > the numerologists slightly less ammunition to tell us what the spirits of our > ancestors are trying to tell us through tea leaves and tattooed chicken bones.
I'm not particularly happy with any system that is totally arbitrary, be it an arbitrary declaration of a major/minor update to reduce numbering conflicts or a arbitrary decision that we only use x.5.y or x.0.y in our version numbers. The engineer in me says that we're wasting a lot of in-the-middle numbers with that, even if numbers are very cheap. > Note also that the push-to-1.0 approach came about because Allison said "Screw > this milestone approach with its major features; let's just set a hard > deadline and start throwing out non-critical features." I'd hate to let the > infatuation with what's major and what's not creep back in and siphon away > this great momentum we seem to keep building. I like momentum, and ever-embiggening numbers is a perfectly cromulent way to keep it going. Just as stupid it is that the Linux kernel version number string is about 50% "stuff that probably wont ever get changed", it's also going to look pretty lousy for us to take a random string of numbers that looks like we pulled them out of a hat. I would much rather prefer a version string that meant something real, like 2009r1 or r1.1 (... r1.12, r2.0) Then numbers that are completely arbitrary and that we try to stretch to fit what a real calendar looks like. The former would make our deprecation policy much easier: We don't support any version where the year in the version number doesn't match the year you see on a current calendar. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
