Brave new (1.0) world.
chromatic at wgz.org
Thu Feb 19 20:46:37 UTC 2009
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.
Very few roadmap features are blockers, and I don't believe we have any
blockers yet for 1.5 or later.
> 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.
> 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.
> 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?
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.
More information about the parrot-dev