river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: svn commit: r601098 - /incubator/river/trunk/jtsk/doc/release-notes/index.html
Date Wed, 05 Dec 2007 07:53:45 GMT
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