Brave new (1.0) world.

[Will Coleda]

This addresses most of the questions I just shot off (thanks), except
for one (see below with a few other comments)

On Thu, Feb 19, 2009 at 3:14 PM, chromatic <chromatic at wgz.org> wrote:
> 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.

Note that your document here conflicts in some ways with Allison's
Vision for 1.0 document; If your document is canon, let's update or
remove her document. For those of us who weren't privy to the original
discussion, these documents are all we have, and it's important to
keep them unified.

I think that the support document can also be updated with stronger
verbiage to reflect your comments in this thread. I can proffer a
patch after this thread settles down.

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

This is the unanswered question for me: What are you planning on
calling the 5 releases between 1.0 and 1.5, if we're avoiding magic
numbers aside from the milestone releases?

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

Side note: deprecation.pod has been ignored several times in the past
few months. A more rigorous definition of what can be changed without
adding a note in here should be added. (could also be cast as "what's
the PARROT_API?"). This'll help going forward.

-- 
Will "Coke" Coleda