+1 to David's recap and to Matts plans below.
John
Matt Hogstrom wrote:
Thanks David, I tried to recap in the other thread and didn't receive
any additional responses so now that we have a branches/1.1.0
branches/1.1 and a branches/1.1.1 I don't think we quite nailed it.
Your summary is great and I concur.
Here is my + 1 and I'm happy to get the Wiki updated.
The remaining question is what to do with the branches that are out
there. I think we should whack what's out there (does not appear that
there has been any activity) branches/1.1 and branches/1.1.1. When
the vote is complete later today and we release 1.1 I'll move
branches/1.1.0 to tags/1.1.0 and then make the copy to branches/1.1
and update the versions to 1.1.1-SNAPSHOT as well as the plugin releases.
Then I think we're open for G-Business.
David Blevins wrote:
We had this whole conversation last week, lots of good discussion was
had. I'd prefer not to have to have it again. Here is my exact
understanding of our consensus and would like to put it to a vote to
avoid reinterpretation of that consensus in the future.
1. branches/x.y would be the branch for all x.y.z releases
2. when a release is frozen, we spin off a branch with that *exact*
name, as in branches/x.y.z, where z starts at zero and increments
by one.
3. at that time branches/x.y is immediately updated to version
x.y.(z+1)-SNAPSHOT
3. We cut releases from the frozen branch
4. When a release passes final tck testing and final vote, the
frozen branch is moved to tags
We create a branch at freeze time for the following reasons:
1. it takes *at least* one week from freeze to ship due to voting,
tck testing and potential repeats of that process (re-cut,
re-certify, re-vote). There is no reason why work on x.y.z+1
needs to be delayed -- only 52 weeks a year.
2. stronger guarantee no one is updating the branch once frozen
3. less likely that people and ci systems (continuum) will checkout
and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
would need to be removed manually and may accidentally be
distributed.
4. it is currently very difficult to roll version numbers forward,
entries here and there are often missed. Far better to have
branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
than a few overlooked x.y.z final numbers that needed to go back
to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
back later if that process happens in the frozen branch.
Here is my +1
-- David
On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
After the branches/1.1 was moved to tags there was some question as
to what happened to the 1.1 branch. At that time some kind soul
created a new branches/1.1.1. No activity has occurred in that
branch and given that we'll need to define the release goals of
1.1.1 soon I'd like to propose the following.
After 1.1 is released:
* Delete branches/1.1.1
* Move branches/1.1.0 to tags/1.1.0
* Copy tags/1.1.0 to branches/1.1.1
* Update branches 1.1.1 to be 1.1.1-SNAPSHOT
* Start working on 1.1.1
When 1.1.1 enters time for release
* Move branches/1.1.1 to branches/1.1.1.0
* Change version from 1.1.1-SNAPSHOT to 1.1.1
* Create release candidate rc1
* put out for a vote
* get a successful vote with no respins :)
* move from branches/1.1.1.0 to tags/1.1.1.0
Based on all the confusion in the past I think this procedure makes
it clear what phase were in for the release as well as avoids
tagging and branching repeatedly.
I'm looking for lazy consensus and not a formal vote.
Matt
