Brave new (1.0) world.

[Will Coleda]

On Thu, Feb 19, 2009 at 3:46 PM, chromatic <chromatic at wgz.org> wrote:
> On Thursday 19 February 2009 12:33:30 Will Coleda wrote:
>
>> We're not defining milestones by added features, but by what we can remove?
>
> We *expect* that the milestones will contain the features in the roadmap, but
> few of those features are sufficient to block the milestone release.
>
> For example, we'll release a new version of Parrot on 17 March.  It'll
> probably be 1.0.  If we completely fail to provide the ability to build dynops
> and dynpmcs from an installed Parrot by that release date, we *may* not
> release that version as 1.0, because it's a blocker.

So, the dated milestone releases are NOT purely date based. Now I'm
very confused, unless this is a special case for 1.0.[1]

So the milestone releases ARE somewhat feature based. So now I'm back
to confused, because I had just accepted that they were timed. So if
something can block 1.5, then there IS something special about that
release aside from the deprecation timelines.

Why should anything block 1.5? It seems to follow from your arguments
that there can be no such thing as a blocker for a release. The number
will increase monotonically; the numbers every six months are special
only because they assure users we won't remove something they were
looking for. No?


> Very few roadmap features are blockers, and I don't believe we have any
> blockers yet for 1.5 or later.

[1]Ok, not a special case for 1.0

>> Ok. Then we should make it clear that the features that we have listed
>> for the various releases in Roadmap are just suggestions. That's not
>> how I'm currently reading that.
>
> Okay, but that's how they've always been, with the exception of blockers.
> That's a *feature* of time-based releases, as I see it.

(always been) Perhaps this was something obvious to the folks at PDS.
It was not obvious to me, or I probably wouldn't have started this
thread.

>> Unfortunately, with milestone releases numbered (e.g.) 1.5, we  can't
>> avoid the major/minor/patchlevel scheme, since we don't have enough
>> numbers. Any suggestions on how to resolve the desire to avoid special
>> numbers and yet keep milestone releases (which are now just date based
>> and driving deprecations) with an obvious numbering scheme?
>
> The date-based numbering scheme was my attempt to do so.

Ok, but we don't have that now. So we have to come up with an attempt
here. Here's mine: make the milestone releases every six months be
1.0, 2.0, 3.0, and have the monthly releases be 1.1, 1.2, 1.3 , etc.

>> We also need to really well document the plan here, because as a user,
>> if I see parrot 2.0 vs. parrot 1.0, and it doesn't have any new
>> features, I'm going to be very confused. Proof: I'm already confused.
>
> Who says there won't be any new features in nine months?

I was exaggerating for effect. If 2.0 is only bugfixes compared to 1.0
(or 1.5), your average parrot consumer will be confused sans
documentation.

> The single question a version number can answer unambiguously is "Which
> release is newer?"  Anything else is numerology.
>
> (No, seriously.  Anyone who claims that the major.minor.patchlevel numbering
> scheme made most prevalent by the Linux kernel indicates something meaningful
> should look at what the Linux kernel does now -- and especially their
> guarantees of backwards compatibility.)
>
> Carrying that line of reasoning, however, who says what's a new feature and
> what's a refinement of an old feature?  Who says which feature is major and
> which feature is minor?  Who says that a minor change isn't widely used in the
> DarkPAN world and will cause lots of people to grit their teeth and curse us
> as they rewrite millions of lines of code?
>
> Now try to cram all of that uncertainty into a single, unambiguous version
> numbering scheme without having to explain it in the kind of policy document
> we already have and which people should read already.  Good luck.
>
> -- c
>

These are all good questions which point to me patching the support
policy docs so at least I am unconfused by the plan, at least now that
I vaguely understand it. I'm not saying I don't like the plan.



-- 
Will "Coke" Coleda