accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: [DISCUSS] How to generate RC's
Date Fri, 10 Jan 2014 16:37:27 GMT
For #1, we typically haven't had a need/desire to keep around how we got 
to a release (the RCs), but just the final release itself. If this is 
something that has merit to it (besides trying to avoid the same 
mistakes in future releases), I can't think of a good one. Maybe putting 
an RC-X note in the commit message would be sufficient?

#2, we could. I think the way Mike has this laid out is a little more 
secure against people working already working on things for the next 
release (or people who are still working on known bugs in a RC), but 
they both do the same thing.

Mike -- whatever we finalize on, we can use ACCUMULO-1468 to document 
this. Perhaps we can also put down the info you used for 1.4.4 with the 
git-archive? We also should transcribe the mvn-deploy info from 
Christopher that I have linked in the ticket.

On 1/9/14, 9:27 AM, Bill Havanki wrote:
> 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

View raw message