On Sun, Dec 16, 2012 at 11:43:12PM +0100, David Nadlinger wrote: > On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote: > >This sounds to me like a bad idea. And indeed, I haven't heard of > >any other project doing this. > > Having release branches is a common practice for many open source > projects. For example, KDE creates a branch per minor release, with > patch releases being made off that branch. LLVM also has a branch > for each release. [...]
Not just open source projects; at my day job, we do this as well. Development continues on the main branch, and releases are branched off this main branch at various point. We don't release immediately after branching, but run development in parallel for a period of time until the code to be released is well-tested and stabilized. Then a release is made. After a release is made, critical bugfixes and major issues are still being made to the release branch, and patch releases are issued periodically from the release branch. Sometimes we go up to two different release branches receiving bugfixes before the older release is phased out. Bugfixes made to the release branches are propagated to the development branch where applicable. Usually, if the corresponding piece of code hasn't changed much, the same bug exists in both places and generally the same fix applies to both of them. Usually, if the code has diverged significantly, the bug doesn't exist in the new code and the fix can just remain in the release branch. (Sometimes two different fixes are needed for the same bug 'cos the code has diverged a lot, but then it can be treated as two separate bug fixes.) Furthermore, sometimes a critical bug is found in the release branch but the fix is already in the development branch. In that case, we backport the fix from the dev branch, which may sometimes require significant changes in order to account for the code divergence between the two branches. Or if even that is insufficient, we have to make a fix specific to the release branch. Anyway, I'm saying all this to point out that we should not get too worked up about the exact details of how all these things work; in practice, things will always be far more complicated than the idealized model of the release process that we put on paper. Let's just concentrate on the most salient points of it -- what branches there are, when we use them, what is necessary to port bugfixes across them, etc., and leave the details to the actual people doing the work. Trying to dictate everything down to the fine points is a waste of time, because the core devs probably aren't going to follow it anyway. T -- Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world. -- Carl B. Constantine