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
