On Friday 20 February 2009 11:51:06 Allison Randal wrote: > Incrementing the major version number every year is already pretty > extreme, but seems appropriate given how the fast Parrot core is > developing over the next couple of years. Incrementing it every 6 months > presents an unprofessional image, a sense of instability, that Parrot is > changing all the time. That's our biggest problem at the moment, we > can't get into distributions because they need stability, and we're a > moving target.
How does parsimony of major version numbers help stability? If we *really* cared so much about stability (in the Jarkko's Signature sense), we wouldn't have six month deprecation cycles. As we *do* have six month deprecation cycles, and six month planning cycles, and six month support cycles, perhaps our version numbers should reflect those six month cycles without requiring us to play games with minor and subminor version numbers. No games. No magic. No hiding reality. Simple to explain. Simple to understand. Has at least some connection to the mythical golden standard of free software revision numbers that people keep bringing up, in the sense that an incremented major version number means you should pay attention to deprecations and other backwards-incompatible changes. (I suspect the *actual* reasons we can't get into distributions are that Parrot hasn't been usable when installed, that nothing else depends on Parrot, that our tests don't pass on all platforms reliably, and that no one's sufficiently motivated to build packages and keep them up to date, not version numbers -- goodness knows, people package Emacs and Enlightenment and Mplayer all the time, with their bizarre version numbers.) > And yes, this does mean we're paying some attention to the value > outsiders attach to version numbers, even if internally we put more > value on the monthly releases. Any versioning scheme which pays more attention to opinions which may or may not exist of people who we haven't ever measured or asked for opinions than to actual realities of the project is a *bad* versioning scheme -- not just a poor versioning scheme or a confusing versioning scheme, but an actively bad and perhaps malicious versioning scheme. I haven't heard *anyone* else claim to like the x.0 -> x.5 version numbering scheme. Let's put it to a vote. Finally, I don't care one bit for the concerns of a mythical potential user who cares more about a number changing on the wrong side of a decimal point than us making and meeting committments regularly. If going from 1.0 to 2.0 in six months instead of a year drives people away, I'll hand draw them a map and circle all of the diners with good pie and bacon. That just leaves more room for grownups who appreciate grown-up software development and gives us more time to focus on *important* features such as accurate documentation, better internals, and optimization. -- c _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
