Brave new (1.0) world.

[Geoffrey Broadwell]

On Thu, 2009-02-19 at 12:14 -0800, chromatic wrote:
> Here's the fundamental problem.  You and everyone else are taking baggage from 
> who knows how many other separate projects and trying to cram all of those 
> different things into a single version number.  Please stop.  All it does is 
> sow confusion.

No one was confused, until the PDS ... when y'all decided to break with
*Parrot* tradition, which happened to align with all of that other
baggage.

> *That* is the only binding set of rules as to what this all means, not what 
> the Linux kernel or Apache httpd or FreeBSD or whatever other project does or 
> how they choose numbers.

Sure.  But let's be honest here -- if our "binding set of rules" differs
in a major obvious way from most of the other major projects in the FOSS
world, it will sow confusion.  Proof: Will is already confused.  ;-)

> We release a new stable version every month, based on elapsed calendar time, 
> not feature set.
> 
> We have two deprecation boundaries every year, based on elapsed calendar time, 
> not feature set.

Yes, agreed entirely.

> Version numbers reflect elapsed calendar time, not feature set.
> 
> If there's been only one commit to Parrot in a month, and if that commit 
> leaves Parrot passing all of its tests on all of its core platforms, we'll 
> realease a new version anyway, because even a single commit is visible 
> progress.  We'll also bump up the version number, because version numbers 
> reflect that version x + 1 is an improvement over version x.  That's all.

OK, that's fine.  I think it throws useful information away ... but I
don't care *enough* to fight that.  (Please don't construe the stuff
below as continuing to fight your basic decision -- but I do believe I
left some misconceptions that I'd like to clear up.)

> (The reason version numbers in the long term roadmap are n.0 and n.5 is 
> because we couldn't quite agree that version numbers of the form 20090417 were 
> better than 1.0.)

Fair enough.  Then please, rather than n.0 and n.5, use n.0 and (n+1).0;
reserve the second digit *purely* for the monthlies.  At least then we
can salvage some useful structural info if we're not going to have birth
date info.

> > It may be numerology, but it's numerology with fairly strong conventions
> > -- and thus provides a useful cognitive structure for communicating our
> > intent with each release.
> 
> *What* intent is that, beyond "We've improved Parrot beyond last month's 
> release.  You should upgrade." ?

Any of:

  * Monthly progress; some bugs fixed and minor backwards-compatible
    features added, upgrade should be always a win

  * Deprecation boundary; backwards-incompatible changes have happened;
    upgrade may require more work than just re-running your test suite

  * Major new features; expect more puppy dogs and rainbows than before;
    you may need to do significant work to make use of new shiny bits

Knowing that kind of info at a glance seems useful to me.  I respect
that you disagree.

> > I can't speak to the other projects, though; they may indeed be blocked
> > by hard-headed feature requirements.  Personally I think parrot's
> > requirement should be "*some* set of big important features is ready",
> > not "this *exact* set of features is ready".
> 
> We haven't had that criterion for multiple years -- years in which we've 
> successfully released a new version of Parrot within a day of the target every 
> month.  It'll take a lot of convincing to change my mind, at least, that we 
> should drop something that's worked so well.

I was not clear; I meant that we should stick with our old rules.  I was
not satisfied with the new concept of a milestone, and thought we were
doing pretty well with our versioning so far.  I was also saying that
strict adherence to a fixed feature set was not my goal -- and
incidentally I don't think it had been true for the project in the past.


-'f