Next focus: PROCESS

[H. S. Teoh]

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