Looks good to me. I don't think it's too much work in the big picture --
it's what's necessary to get it done properly given the tool.
The only ambiguity I see is in 3a), "make corrections _on x.y.z-SNAPSHOT_".
Let's make sure this (assuming there aren't any objections) gets up on
the site.
- Josh
On 1/8/14, 7:58 PM, Mike Drob wrote:
Taking this conversation from IRC because it probably needs to be on the
mailing list at some point. Also, we'll want to update the site when we
have something we are happy with. Thanks to Christopher and Josh for the
thoughts they've already contributed to the discussion.
We need a standard procedure for generating RCs that is:
1) Easily reproducible
2) Compatible with ongoing development
3) Compatible with our git branching model.
The proposed process is:
1) Create an RC branch named x.y.z-rcN from (the tip of) x.y.z-SNAPSHOT
2) Commit pom version changes to the branch, tag as rc, and push
3) Perform testing and voting as necessary
3a) If the vote fails, make corrections and start over at 1)
4) After a vote passes, tag the release on the same commit that was the rc
5) Apply additional pom changes (i.e. increment to next SNAPSHOT version)
6) Create a new development branch x.y.a-SNAPSHOT based on the current tip
of x.y.z-SNAPSHOT
7) Merge tag + version increment into x.y.a-SNAPSHOT branch
8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
After having typed that all out it kind of seems like a lot of steps to go
through, but on the other hand, we're not going to be doing everything at
once anyway.
Additional feedback would be awesome.
Mike
