On Sun, Mar 22, 2009 at 10:17:42PM -0400, Eric S. Raymond wrote: > Mark de Wever <[email protected]>: > > 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 don't see that this differs much from what we've *been* doing, frankly.
Uhm I don't consider the last weeks of 1.6 only small bug fixes and minor commits. So the change would be instead of having released 1.6 start the rc phase at that point. -- Regards, Mark de Wever aka Mordante/SkeletonCrew _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
