river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject [VOTE] Branching Strategy River
Date Mon, 14 Jan 2008 22:16:53 GMT
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 = 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.


   .../river/<product>/trunk    - mainline development
   .../river/<product>/branches - maintenance branches
   .../river/<product>/tags     - frozen release tags
   .../river/<product>/skunk    - development and 'skunk works' branches

     |----------  /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/

View raw message