Simon,
> The point I have made is that I disagree with a feature freeze date
> fixed ahead of time without regard to the content of the forthcoming
> release. I've not said I disagree with feature freezes altogether,
> which would be utterly ridiculous. Fixed dates are IMHO much less
> important than a sensible and useful feature set for our users.
This is such a non-argument it's silly. We have so many new major features for 9.1 that I'm having trouble writing
sensiblepress releases which don't sound like a laundry list.
> MySQL
> repeatedly delivered releases with half-finished features and earned
> much disrespect. We have never done that previously and I am against
> doing so in the future.
This is also total BS. I worked on the MySQL team. Before Sun/Oracle, MySQL specifically had feature-driven releases,
whereMarketing decided what features 5.0, 5.1 and 5.2 would have. They also accepted new features during beta if
Marketingliked them enough. This resulted in the 5.1 release being *three years late*, and 5.3 being cancelled
altogether. And let's talk about the legendary instability of 5.0, because they decided that they couldn't cancel
partitioningand stored procedures, whether they were ready for prime time or not and because they kept changing the API
duringbeta.
MySQL never had time-based releases before Oracle took them over. And Oracle has been having feature-free releases
becausethey're trying to work through MySQL's list of thousands of unfixed bugs which dates back to 2003.
An argument for feature-driven releases is in fact an argument for the MySQL AB development model. And that's not a
companyI want to emulate.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco