Janek Warchoł <janek.lilyp...@gmail.com> writes: > On Mon, Mar 11, 2013 at 3:37 PM, David Kastrup <d...@gnu.org> wrote: >> >>> Add some doc updates and translations if they are available, or make >>> them known issues if not. As Janek says, anything else goes into a >>> branch. >> >> That's exactly what the disagreement is about. This "anything else goes >> into a branch" is not a requirement as long as we are not shaping up for >> an eventual stable release. > > Ah, you mean that the disagreement is /only/ about whether we should > flip the switch (make a branch) now or later? > If so, i'd say we can do this now. Let's see what Mike will say.
Uh Janek? We have _never_ made a branch for stable releases until after we reached a state of convergence. The problem is that in order to get a stable release from a wobbly starting base, we need testers. If all developers move on to the unstable branch and the unstable branch gets extensive work, testing of the fixes required to get a release ready will fall apart. After cutting the stable release branch, what goes in there are documentation fixes, well-exposed cherrypicks of bug fixes, and reverts of regressions. Basically stuff that is _certain_ to improve release quality, judging from the beating it has seen in master because, like it or not, that's what people are working with and looking at. If the unstable branch gets _extensive_ changes, this approach falls down. Cherry-picking stops working, documentation changes in unstable and stable are not exchangeable, and so on. Last time around, we released 2.17.0 in the _wake_ of releasing 2.16.0, and only _then_ the extensive skyline patches were placed into 2.17 and 2.17.1 was released with them. That worked reasonably well. We don't have the resources for parallel development and testing, and it does not even appear that we have the release mechanisms. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
