river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Venners <bv-...@artima.com>
Subject Re: [VOTE] Branching Strategy River
Date Tue, 15 Jan 2008 20:12:00 GMT

+1 Works for me. I especially like the skunk branch.


On Jan 14, 2008, at 5:16 PM, Mark Brouwer wrote:

> Given a lack of participation related to the branching strategy for  
> the
> Apache River project a vote is issued to bring it to the attention of
> all. The branching strategy is mentioned below the check boxes.
>
> Please cast your vote:
>
>  [  ]   +1  I agree with this branching strategy
>  [  ]    0  I don't feel strongly about it, but I'm OK with this
>  [  ]   -1  I disagree with this branching strategy for the reasons
>             mentioned below
>
> The vote will be open through Thursday, January 17th.
>
> ---------------------- Branching Strategy River -------------------
>
> Version Numbering
> -----------------
>
> Each Apache River deliverable has a version number of:
>
>  m.n.r
>
>  m = major version
>  n = minor version
>  r = maintenance version
>
> The major version number will in general only be increased in case of
> major changes that might introduce compatibility problems or represent
> some fundamental improvements. The minor versions reflect the various
> feature releases, the last part of the version number reflects the
> maintenance release.
>
>
> Branching Policy
> ----------------
>
> Ongoing development for the next release takes place in the trunk.  
> Once
> feature complete for a (non maintenance) release the trunk is branched
> into /branches/<m.n> which in general also reflects the moment a  
> release
> candidate is presented to the public in a fairly short period of time.
> Ongoing development continues in the /trunk, issues found against the
> release candidate will be fixed in /branches/<m.n> and likely merged
> into the /trunk.
>
> Once a release candidate is ready for a first customer release
> /branches/<m.n> is branched into /tags/<m.n.0>. When support is  
> required
> for a particular release m.n, the development for a fix-release is
> conducted in /branches/<m.n>. When a bug-fix release is ready it is
> branched into /tags/<m.n.r> where r is a positive number and increased
> for each maintenance release.
>
> Although ongoing development should take place in /trunk, there is a
> /skunk branch that can be utilized for 'experimental' work that must  
> not
> disturb the /trunk, that needs to be visible to others and/or might
> require participation of others. In general the lifetime of such  
> branch
> should be short to give it a chance of successful integration into the
> /trunk when the 'experiment' has been found valuable.
>
> Summarized:
>
>  .../river/<product>/trunk    - mainline development
>  .../river/<product>/branches - maintenance branches
>  .../river/<product>/tags     - frozen release tags
>  .../river/<product>/skunk    - development and 'skunk works' branches
>
>
>  /trunk
>    |
>    |
>    |----------  /branches/2.1/
>    |          \
>    |           \
>    |            \ -------  /tags/2.1.0/
>    |             \
>    |              \
>    |               \ -------  /tags/2.1.1/
>    |                \
>    |
>    |
>    |---------  /branches/2.2/
>    |         \
>    |          \
>    |           \ -------  /tags/2.2.0/
>    |            \
>    |
>    |
>    |---------  /skunk/<catchy_name>
>    |
>    |
>    |----------  /branches/3.0/
>    |          \
>    |           \
>    |            \ -------  /tags/3.0.0/
>    |             \
>    |              \
>    |               \ -------  /tags/3.0.1/
> -- 
> Mark
>
>
>


Mime
View raw message