river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: [VOTE] Branching Strategy River
Date Mon, 14 Jan 2008 23:14:20 GMT
+1

I'm not a stakeholder, but this strategy makes perfect sense.

Craig

On Jan 14, 2008, at 2: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
>
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message