Wireshark · Ethereal-dev: RE: [Ethereal-dev] Creating a stable branch

["Maynard, Chris" <Christopher.Maynard@xxxxxxxxx>]

My 2 cents regarding branches:  I have been taught, by Afora
International (http://www.afora.nl/index.shtml), to keep things as
simple as possible.  From what I learned and from my own experience, I
would recommend a branch strategy that involves essentially only 2
branches - a trunk and an active development branch where heavy
development is done on the active development branch only, and releases
are made on the trunk.  In a nutshell, it looks something like the
following:

DEVELOPMENT BRANCHes

        b1         mb1             b2        mb2           b3
        ^~~~~~~~~---               ^~~~~~~~---             ^...
       /            \             /           \           /
      /              \           /             \         /
--0.10.14             v~~-----0.99.0            v~~----0.99.1
                      mt1                       mt2

TRUNK (STABLE BRANCH)

.... where:
1) "-----" implies stable code
2) "~~~~~" implies unstable code
3) "v", "^" indicate the branch/merge directions
4) "m" is a merge point, with "b" on the branch, and "t" on the trunk.
5) Both branch points and merge points are always tagged.

Some things to note:
1) Development is never done on the trunk, except for perhaps a very
short time when merging from the development branch to the trunk in
preparation for a release, as unforeseen problems are always possible.
This is normally a very short period of potential instability, and any
changes made to the trunk during this time will of course need to be
merged back to the development branch eventually.  Proper tagging allows
merging to be as painless as possible.

2) The way I've shown the graph, I allow development to be done on one
branch - either the current development branch or the trunk when
preparing for a release, but never both.  This prevents more development
on a soon-to-be retired development branch.  This does not have to be
the case though.  Development could continue on b1 even after mb1, but
then any changes after mb1 would have to be merged into the b2 branch on
some other merge point.  In reality, once b2 starts, there is no reason
to continue on b1.

3) Bug fixes are normally done on the development branch as well, and
also merged in along with the new features to the trunk when the next
release is desired.

4) If a critical bug is found and must be fixed for an emergency release
before the next scheduled release, it can be fixed on the trunk to avoid
a hasty merge from the development branch which might not be ready for
merging, but then it would have to be tagged and a merge from the trunk
to the current development branch would need to be done to make sure the
bug fix was also applied in the development branch.  (I did not show
this example on the above graph.)

There are many complications that can arise and I am simplifying
somewhat.  In any case, I think it's far easier to only have to worry
about at most 2 branches at any one time, and IMO, this model should
work rather well for Ethereal development.

Lastly, here's a link to an Open Source book written by Karl Fogel &
Moshe Bar entitled, "Open Source Development with CVS":
http://cvsbook.red-bean.com/. I realize that Ethereal uses Subversion
now, but many of the concepts are the same.  The book itself is open
source (http://cvsbook.red-bean.com/images/paraglyph-letter.jpg).  A
good place to start reading about branching is page 152, "Going out on a
Limb...". On page 162, Karl refers to the branching method I illustrated
above as, "The Flying Fish Approach".

FWIW,
Chris 

-----Original Message-----
[some snipping here]
 
> Ulf Lamping wrote:

> However, I'm *really* unsure if we can provide the effort of
maintaining
> both the developer and the release version. After a relative short
time,
> both versions will differ a lot, so merging changes from the release
to
> the devel or vice versa are practically impossible, resulting in
having
> to code two implementations for a bug fix (doing bug research twice,
> etc.), which is obviously annoying.
> 
> Another problem is: When to release a new stable version? Doing a
> release too late results in a lot of double effort and releasing it
too
> early results in several new fresh bugs.
> 
> Maybe I'm looking at things to complicated and this will work
perfectly :-)

Gerald Combs wrote:

You probably aren't.  My main focus is making our development process
more secure.  If you can come up with a way to do this that's simple and
easy, I'm all ears.  :)


-----------------------------------------
This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention,
distribution or disclosure by others is strictly prohibited. If you
are not the intended recipient (or authorized to receive for the
recipient), please contact the sender by reply email and delete all
copies of this message. Also, email is susceptible to data
corruption, interception, tampering, unauthorized amendment and
viruses. We only send and receive emails on the basis that we are
not liable for any such corruption, interception, tampering,
amendment or viruses or any consequence thereof.