Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> [DISCUSS] How to generate RC's


Copy link to this message
-
Re: [DISCUSS] How to generate RC's
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 <[EMAIL PROTECTED]> 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
>>>
>>>
>
>