Brave new (1.0) world.

[chromatic]

On Thursday 19 February 2009 12:00:35 Geoffrey Broadwell wrote:

> On Thu, 2009-02-19 at 11:09 -0800, chromatic wrote:

> > They are.  They're the milestones after which we start removing
> > deprecated features.
> That's not a milestone in the sense that I think is most commonly used
> -- it's more of a "deprecation boundary".

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.

At the PDS, we discussed our support and release and deprecation policies, and 
I wrote all of that into a single document which describes our release process 
and support policies and deprecation plans.

*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.

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.

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.

(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.)

> 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." ?

> 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.

> If you want to completely remove any useful information about the
> release other than order, then release date makes a fine "version", as
> Will has pointed out.  But you'd damn well better have some other very
> terse and easy to understand way to tell people whether they should care
> about upgrading. (Yes, I know, you'd be very happy if people *always*
> upgraded.  But you're the same one advocating breaking backwards
> compatibility regularly, so you can't have both.)

Please read the release, support, and deprecation documentation, as it answers 
all of those questions.

-- c