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.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
