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: svn commit: r601098 - /incubator/river/trunk/jtsk/doc/release-notes/index.html
Date Fri, 14 Dec 2007 18:22:19 GMT
Just a few comments on the picture. Basically it's fine and  
consistent with good engineering practice, and consistent with other  
projects at Apache.

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.

Craig

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

> 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/
>>    |            \
>>    |
>> Applying the branching strategy as above will result in the  
>> ability to
>> keep the pace in the trunk without influencing the codebase that is
>> about to be released. My experience is that between feature ready  
>> and a
>> final release there are always these last minutes issues that pop up
>> need to be resolved, if not that is great, if so there is a place  
>> for it
>> by default.
>
> I think we should decide about our branching strategy, this I  
> believe is
> 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
> both the trunk and the maintenance lines and flow back to their  
> origin.
> -- 
> 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