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

[Gerald Combs <gerald@xxxxxxxxxxxx>]

I agree that the number of active branches should be kept to a minimum.
 If I understand the branching section of the CVS book correctly, both
the Flying Fish and Dovetail models assume that merging will be
bidirectional, with changes going back and forth between "development"
and "stable".  What I had in mind is a simplified version of what the
FreeBSD folks are doing:

Borrowing from you, Ulf, and the FreeBSD document we'd have

    0.99.0  ...  1.0.0    1.99.0  ...  2.0.0
      /     /      /        /      /     /
 releng_1~~---------   releng_2~~~--------
    /                     /
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> trunk

At any given time there'd be two active branches: "trunk" and "releng".
  The trunk would receive the current volume of changes.  With
reasonable exceptions, changes to the "releng" branches would be
low-volume and limited to

  - Code necessary to meet milestones
  - Security and bug fixes
  - Documentation updates
  - Minimal-impact dissector updates, e.g. new RADIUS dictionary entries

These changes may or may not come from the trunk, but they'd be
unidirectional.  I don't foresee having changes go from a "releng"
branch _to_ the trunk.


Maynard, Chris wrote:
> 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.
> 
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev