On Thu, 2009-02-19 at 11:09 -0800, chromatic wrote: > On Thursday 19 February 2009 10:33:21 Will Coleda wrote: > > If we're calling 1.0/1.5/2.0 -milestone- releases, then they should > > actually be milestones. [1] > > They are. They're the milestones after which we start removing deprecated > features.
That's not a milestone in the sense that I think is most commonly used -- it's more of a "deprecation boundary". > I would very much like to drop major.minor.patchlevel version numbers and all > of the assorted numerology that goes along with them. It may be numerology, but it's numerology with fairly strong conventions -- and thus provides a useful cognitive structure for communicating our intent with each release. > > I would rather see the feature set required for milestone releases be > > fixed (or at least fairly firm), have monthly releases of the 1.0 > > milestone branch occur until 1.5 is ready to ship, and then update the > > release date to "whenever it happens.". > > I've seen plenty of projects set a hard feature set and slip releases by > months or years. See Debian, Perl 5.10.1, Django, Gentoo.... Debian's problem is not a hard feature set; key features often go in (relatively) quickly into a new release cycle, and many more are dropped later because they don't make it in time. The Debian delays are because of A) a hard stability requirement before release, and B) constant squabbling about binary firmware blobs that require invoking certain very slow procedures in their constitution. I can't speak to the other projects, though; they may indeed be blocked by hard-headed feature requirements. Personally I think parrot's requirement should be "*some* set of big important features is ready", not "this *exact* set of features is ready". > That's exactly the kind of numerology I want to avoid. Version numbers > should > always increase. That's all you can say about them. That's a fine stance, but it completely ignores culture -- and in particular, a culture that Parrot itself has been a part of for years now. If you want to completely remove any useful information about the release other than order, then release date makes a fine "version", as Will has pointed out. But you'd damn well better have some other very terse and easy to understand way to tell people whether they should care about upgrading. (Yes, I know, you'd be very happy if people *always* upgraded. But you're the same one advocating breaking backwards compatibility regularly, so you can't have both.) -'f _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
