Re: [VOTE] Branching Strategy River

[Craig L Russell]

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


feature complete for a (non maintenance) release the trunk is branched

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

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

disturb the /trunk, that needs to be visible to others and/or might

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



  /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

Ongoing development for the next release takes place in the trunk. Once into /branches/<m.n> which in general also reflects the moment a release /branches/<m.n> is branched into /tags/<m.n.0>. When support is required /skunk branch that can be utilized for 'experimental' work that must not require participation of others. In general the lifetime of such branch .../river/<product>/skunk - development and 'skunk works' branches

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

smime.p7s
Description: S/MIME cryptographic signature