Brave new (1.0) world.

[Will Coleda]

On Thu, Feb 19, 2009 at 4:12 PM, chromatic <chromatic at wgz.org> wrote:
> On Thursday 19 February 2009 12:57:10 Will Coleda wrote:
>
>> > 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]
>
> We don't have any blockers for 1.5, so I'm willing to say that this is a
> special case for 1.0.  Of course, we haven't gone through a detailed planning
> session for much beyond 1.5, so who knows?
>
>> 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?
>
> That's how I see them, yes.  We're not going to hold a feature we've planned
> to be in 1.5 if we get it done the day on 18 March.  We're also not going to
> make a new stable release then either.  We release a new stable version of our
> software on the third Tuesday of every month.
>
>> > 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.
>
> Why?  Why such a focus on version numbers?  Who *cares* what a version number
> is, as long as you can tell unambiguously that one release is newer than
> another release?
>
> Why have we spent such a huge amount of time today arguing over real numbers?

Because the plan as was discussed didn't provide a way to number
things and be consistent. I don't care HOW we're consistent as long as
we are.

Don't think of it as bikeshedding so much as making sure the local
hardware store sells paint. I see they do now. Excellent. I will go
purchase a gallon of their finest.

I'm just trying to understand what the plan is. I think I do now, and
it seems vaguely reasonable. Thank you for explaining your position.

> We're not mathematicians.  We're not theologians.  We're not arguing over
> Planck numbers or fractals or the limitation of human knowledge and
> measurement.  We're just releasing software, one new version every month.
>
> Why does it have to be ANY more complicated than "n + 1 is newer than n"?
>
> (Before anyone responds and says "Deprecation deadlines!" we can just as
> easily remove version numbers from deprecation notices and say "Removed no
> sooner than March 2010" or whenever.)
>
>> 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.
>
> Why?  2.0 is newer than 1.0 or 1.5.
>
>> 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.
>
> Please do patch the docs where they're confusing.  We need to point people to
> those docs early and frequently, especially to set their expectations for
> deprecations and free support.
>
> -- c
>

I'll give anyone else who was a PDS a day or few to confuse me more,
and then update the docs.

-- 
Will "Coke" Coleda