river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Hurley <Jim.Hur...@Sun.COM>
Subject Re: svn commit: r601098 - /incubator/river/trunk/jtsk/doc/release-notes/index.html
Date Wed, 05 Dec 2007 13:14:28 GMT
Thanks Mark.  Definitely go ahead and fix up any HTML bugs you see in  
the Release Notes.

As promised, Sun has been doing some pre-testing on a build (more  
details on
that in another mail), but with the update of the Release Notes, I  
think we're ready
to do an 'official Release Candidate build' and get this release out  
the door.  Bottom line
is that it would be great if you could make any Release Notes changes  
ASAP so we could
build and make available a Release Candidate TODAY. Thanks.

I'm not sure of the right branching and labeling strategy. I think  
most of what you describe
sounds good - but I'll leave the comments to folks with more  
expertise than me.  I think Frank
was planning on labeling the v2.1.1 release in the tree, and then I  
was assuming AR2 work
would commence in the main trunk.

-Jim


On Dec 5, 2007, at 2:53 AM, Mark Brouwer wrote:
> Jim,
>
> The release notes look good to me. There are some HTML bugs in this  
> file that I can fix if you like, let me know if you want me to do it.
>
> Given the fact many committers are grabbing their piece of work as  
> JIRA shows I really think it is time to branch into a version or  
> release branch, or are there some things that needs to be done and  
> that would be a pain to integrate back into the trunk?
>
> About branching I believe we should come up with a strategy for  
> branch names and code evolution. Based on perforce (which has  
> better integration support, so I might be wrong for SVN) I opt for  
> a main branch (the trunk) which should contain the ongoing and  
> latest and greatest development.
>
>   /trunk/
>   /version/2.1/
>   /release/2.1/1/
>   /release/2.1/2/
>
> The version/2.1/ branch is branched from the main branch (which we  
> could do now), the release/2.1/1/ and release/2.1/2/ branch are  
> branched from the version/2.1/ branch.
>
> This way we can provide support in the version/2.1/ for the 2.1.x  
> releases and allows us to make more (temporarily) disruptive  
> changes in the trunk. Emergency fixes for a particular release  
> branch can always applied to the release branch itself without  
> being interfered with work in the version branch. We can always  
> integrate changes from trunk into version if there is a need, or  
> the other way around.
>
> I also think we should change AR1 to AR_2.1.1 in JIRA.
>
> Let me know what people think. I can be a bit more verbose related  
> to the branching policies from a conceptual viewpoint but I hope  
> the above is clear.
> -- 
> Mark


Mime
View raw message