Brave new (1.0) world.

[chromatic]

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