On Tue, Mar 17, 2009 at 05:19:16PM -0400, Eric S. Raymond wrote: > Mark de Wever <ko...@xs4all.nl>: > > > I think the only way we're going to get > > > more user testing is by shipping "stable" releases more often, which > > > is to say seriously shortening our development cycle. > > > > Well the goal was to start to think about how to achieve that wish. > > Since I've no real ideas about what we could do to improve the situation > > I just wanted to start the discussion. > > And quite rightly. This is a good time to have it.
I've done some more thinking about this subject. I think the biggest problem is that it takes about 2 to 3 weeks for bugs to be discovered. So with a lot of last minute changes the odds of bad bugs popping up after this period is rather big. (I also recently introduced a bug which got fixed in 1.6a.) And that we now have 1.6a proves that a lot of big last moment fixes doesn't work. So I'd like to try the following release scheme. x months of development with a release in about every three weeks. y weeks of beta's which starts the hard feature freeze a release in about every two weeks. At this point we should encourage users to start testing. After a few weeks we when we get the feeling things start to stabalize we should start to really encourage users to use it and try hard to keep compatibility between the version. (This is what we call the release candidates at the moment, but I think we shouldn't call it release candidates since we don't intent to release them. If we want a give it a name, different as beta, let's call it pre releases.) Once we think things are stable we fork the trunk into a branch. This means all bugs we know about and want to be fixed are fixed at this point! Then we start to release release candidates and a release candidate should be a release candidate. In the branch there should only be bug fixes, translation and image updates (only the images no config changes). Once we have about three weeks of no bugs or only small fixes we can release the final version. > > I'm not sure whether the shortening the development cycle really helps > > (I think not) but we could try it. The last time we also discussed the > > idea of a half year cycle and rejected it. But since the current model > > also doesn't 'work' in this regard we can at least try it. So if we aim > > for half a year that would be the middle of September, which would also > > fit with gsoc (if we get in). > > I have also, independently, been thinking that September 2009 would > make a good target date for 1.8. That timing seems about right for > both of the major 1.7 projects I know are already scheduled to have > landed and gotten some testing. Those are: > > * The full GUI II rewrite This won't be finished in half a year, but I'm also not sure a year will be sufficient. But it would be nice to determine how long we want to have the 1.7 cycle 6 months a year or something else. This way we can plan what we want to do for the next stable release. -- Regards, Mark de Wever aka Mordante/SkeletonCrew _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
