Re: Branching Practices

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I favor doing development on the main trunk. Branches are use ONLY for
bug fixes and stabilization.

A branch is made from the main trunk to throttle the flow of changes to
increase the stability of the code in the branch. At some point, it is
time to take another branch to be a release candidate. These release
candidate branches will probably never have more than a handful of patch
made to them as the result of a final QA testing effort. The throttle
branch will be used for new minor releases over time and each minor
release will be handled by committing the minimum amount of change
needed to fix a problem.

As it gets closer to time to freeze a release for more serious testing,
it becomes time to create the throttle branch.

Now, every bug found on the throttle branch gets committed first to the
main trunk to find a long term solution. If the fix seems to work
properly, then it is applied to the throttle branch. If there is already
a release candidate, then the patch is applied to the release candidate
branch if it seems to do no harm on the throttle branch.

By doing successive commits to the other branch, the quality of the
patch may become better and therefore reduce the churn of the final
patch that gets applied to something that is closer to being released to
a customer.

Generally, only bug fixes found by unit and system testing get fixed in
the branch and only bugs that directly impact quality go into the
release candidate branch. That is, if you do not have a test for it, you
don't fix it in the branch and if you don't have a bug that will
directly impact funcationality for the customer, it does not go into the
release candidate.

So, if a bug is found that is judged not to be acceptible risk to put
into the branch after it has been tested in the wilds of the main trunk,
it is only fixed in the main trunk and it will have to be some other
patch which is less risky or no patch at all which gets applied to the
throttle branch. In a similar manner, the quality bar should be higher
to get into a release candidate.

Any new feature gets put into the main trunk. If there is a strong need
to port it to a minor release, then it gets ported to the throttle
branch first before it is ever even thought about being merged into an
existing release candiate.

The time between when a release candidate branch is pulled and the time
when the release is made should be as quickly as possible with as few
changes as possible. The idea here is to have a very tight window
between when the first release candidate is made and when the final
product is shipped. Although, it is possible that multiple release
candidates may be needed.

The above mechanism assumes that the main trunk is always the next major
release and the throttle branches off of it will be major releases. The
branches off of the throttle branches will be minor releases and if
necessary there may be multiple patch releases off of a minor release
(that is, you could refine things by creation of yet another level of
branches).

So for example, I might have a top-of-tree main trunk that I consider
release 7.x, the branch tag RELENG_6 might be for the 6.x major release,
the RELENG_6_2 might be the second branch off RELENG_6 and hold the
sources for the 6.2 release.

        Enjoy!
        -- Mark

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQFGsDPbCg7APGsDnFERAl5LAJ9Glaksb+Bw7Bv//PMKy4h3kThVZwCfST7V
4Eohisj0coWIRAMZVjaRT5s=
=jwfJ
-----END PGP SIGNATURE-----