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. -- c _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
