Grand Branching Scheme


Generally, neither the number of developers nor the rate of change is so high
as to justify a highly-organized branching regime.  Also, a significant part
of the quality assurance feedback originates externally, so it is not
practical to assume a highly-organized QA function either.

Since TinyMUX is developed for Win32 and various flavors of Unix, it isn't
possible to know whether code that compiles and runs on one platform will
necessarily compile and run on another.  On the other hand, not all developers
have access to all platforms and are unable to completely verify their changes.

Nevertheless, it makes sense to describe the Grand Unified Scheme for
Branching, and then argue why it can be collapsed and special-cased.


        ----2.6.0---2.6.1
       /
-----------------------------------------------------
trunk   \
         \  dev
          ------------------------
             \
              \  dev_foo
               ----------
                \
                 \  dev_bar
                  ----------
                   \
                    \  dev_baz
                     ----------

In the Grand Scheme, the trunk is never released, and the only changes allowed
are merges from other branches.  It's useful to first classify branches
besides the trunk into development-side branches and release-side branches.
The development-side branches can be organized into a promotion tree like so:

              trunk
                |
                |
               dev
                |
                |------------------
                |        |        |
             dev_foo  dev_bar  dev_baz


An individual developer (e.g., bar) would make changes in branch dev_bar, test
their changes on Win32 and some flavors of Unix.  There is still a strong
desire to see simple changes committed individually -- changes which address
the code in only one dimension to make it easier for others to code review the
changes.  There is also a strong desire to avoid breaking the build in these
private branches, however, the only person affected by a broken build is the
developer who broke it.

Periodically, changes made on dev_foo, dev_bar, and dev_baz branches are
merged into the dev branch, and periodically, changes from dev are merged into
the trunk.  Likewise, changes brought into dev are periodically merged down
into dev_foo, dev_bar, and dev_baz.

The other class of branches are the release-side branches. Periodically, a
release branch is created from the trunk.  Packaging considerations may
require certain minor changes.  Maintenance of a release can be supported with
bug fixes.  Each release branch may require a slightly different fix, but
typically the fix from the most-recently released branch is merged back into
the trunk, and propagated back down the dev tree.

Of course, with all this merging up and down the tree, there is always the
potential for merge conflicts, and these would need to be resolved manually.
Any change to the code should be made in exactly one branch and then allowed
to propagate to everywhere else along with the other changes.

Rather than associate each leaf branch directly with a developer, it is also
possible to create an arbitrary number.  Each developer can then pick for
themselves which leaf they will work in.  This approach would tend to scale
better.

At the moment, however, instead of a Grand Scheme, we have only the main
trunk, and tagged builds. Every developer commits their changes directly into
the main trunk.

In the current scheme, a single person is the gate-keeper.  Patches flow to
this person, and changes made to the repository are at risk of being reverted.
In a more developed branching scheme, control of work is formalized in the
Issue database, and no changes (no matter how mudane) are made unless there is
an Issue that cover and approves it (no matter how mudane).  Furthermore,
instead of a single gate-keeper, each leaf branch can have its own
gate-keeper, impose its own rules, fulfil its internal QA function in its own
way.
