Brave new (1.0) world.

[chromatic]

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