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
