accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Havanki <>
Subject Re: [DISCUSS] How to generate RC's
Date Thu, 09 Jan 2014 14:27:27 GMT
Overall, the process looks good, and I agree with Josh's clarification. Two
pieces of feedback:

1. Step 8 removes a recording of the history leading to the release. For
example, suppose rc1 is no good, and it takes three commits to get to rc2,
which passes. When we remove the rc1 branch, how do we easily figure out
months later which commit rc1 had been based on? (Look at an rc1 JAR
manifest for the hash? eww.) On the other hand, I can see a benefit in
removing inactive branches and tags to reduce clutter.

2. We could save a step, namely #7, by applying the increment to
x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT instead of
on x.y.z. However, this would not leave a linear history, so I leave it to
the more Git-savvy to decide if that is important in this case.

Bill H

On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <> wrote:

> 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

| - - -
| Bill Havanki
| Solutions Architect, Cloudera Government Solutions
| - - -

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message