+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
