Re: svn commit: r601098 - /incubator/river/trunk/jtsk/doc/release-notes/index.html

[Craig L Russell]

Just a few comments on the picture. Basically it's fine and consistent with good engineering practice, and consistent with other projects at Apache.

Craig

On Dec 14, 2007, at 1:41 AM, Mark Brouwer wrote:

I've seen other projects use slightly different terminology and naming schemes. Instead of maintenance, the term branch. Instead of release_2.1, just 2.1. So you would have a root/trunk with continuing development; root/branches/2.1, root/branches/2.2, root/branches/3.0 for development and maintenance; with root/tags/2.1.0, root/tags/ 2.1.1, root/tags/2.2.0, root/tags/2.2.1 frozen after release.

Mark Brouwer wrote:

So ongoing development (latest and greatest) takes place in the trunk, sustaining development for a particular release (m.n.?) will take place in the maintenance branch. "Golden" reference only release are branched

in /tags/release_{m.n.r}/
 /trunk
   |
   |
   |----------    /maintenance/release_2.1/
   |          \
   |           \
   |            \
   |             \ ------- /tags/release_2.1.0/
   |              \
   |               \
   |                \
   |                 \ ------- /tags/release_2.1.1/
   |                  \
   |
   |
   |
   |---------   /maintenance/release_2.2/
   |         \
   |          \
   |           \ ------- /tags/release_2.2.0/
   |            \
   |
   |
   |
   |
   |---------   /maintenance/release_3.0/
   |         \
   |          \
   |           \ ------- /tags/release_3.0.0/
   |            \
   |

keep the pace in the trunk without influencing the codebase that is

final release there are always these last minutes issues that pop up

by default.

Applying the branching strategy as above will result in the ability to about to be released. My experience is that between feature ready and a need to be resolved, if not that is great, if so there is a place for it

something that needs to be resolved before going further.

Are there any reasons why the above branching strategy is not going to
work or is a bad thing. I'm not talking about ad-hoc branching or
branching to enable collaborative development which could branch from

--
Mark

I think we should decide about our branching strategy, this I believe is both the trunk and the maintenance lines and flow back to their origin.

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