[ also resending because the cc keeps getting changed to [email protected] which does not exist!! ]
On Thu, 2009-04-30 at 19:55 +0200, Sven Panne wrote: > Am Donnerstag, 30. April 2009 19:19:54 schrieb Don Stewart: > > We definitely want to avoid a culture of "packing in bug fixes and > > features" prior to release, though, as that's a recipe for new bugs! > > I fully understand this, but due to the extremely poor communication of the > schedule, this is a far better option than shipping something which has non- > trivial bugs. > > I wouldn't propose this if I had known the release date some months in > advance. Expecting everybody to happy when you suddenly shout out a release > date is a bit too much IMHO... You're quite right that the release date has been poorly communicated. I'm sorry about that. It's partly my fault and partly inevitable for a first release (because we cannot release before certain things work). It's also partly that we were not expecting any new releases of any of the packages, so we were not asking maintainers for their updates. All the package versions we're selecting are pretty stable (ie they've been available for some time). The point however is that we're trying to design a release procedure that will scale to many packages and many maintainers. That means time-based releases in future with dates known well in advance. It means trying to get a procedure where we do not have last minute scrambles. We can do that in two ways, having releases sufficiently frequently that there is not this massive pressure to get everything in all at once and two by incrementally freezing changes as we get nearer to a release. For example in the GNOME release procedure (which coordinates ~100 packages and a similar number of package maintainers) they freeze API changes some 4-6 weeks before the release and even code changes are frozen in the week or so before the release. This lets people concentrate on testing the integration. Now, for this release we could say that it's an exception because it's the first one and there was no announced date etc etc and let the GL updates in. But it doesn't really set the right tone if we are already making exceptions to the rules. Under a normal steady-state procedure, if the release were on this coming Monday then it'd absolutely be too late to include any bug fixes from any packages. New features would certainly be out. However even then it would not be a big problem because the next minor release is slated for 4 weeks after the initial release. We've had these GL bugs in the available version since the beginning of November. I expect we can live with them for another 4 weeks. As for new features, there is nothing preventing new releases on Hackage in the 6 months between major releases. So, I apologise for the poor communication with maintainers and I'm prepared to be persuaded if everyone else agrees that version bumps should go in at this stage but my personal opinion is that we should stick for this release and roll the updates into the next minor release in 4 weeks time. Duncan _______________________________________________ Haskell-platform mailing list [email protected] http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
