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
Mike Drob 2014-01-13, 15:17
#1 - No strong opinions.
#2 - I want to make the transition for committers from one branch to the
next as painless as possible. In particular, I'm worried that somebody will
not realize they need to switch branched and accidentally push e.g.
1.4.5-SNAPSHOT after we create a 1.4.6-SNAPSHOT branch. I really really
want just a general 1.4 branch to deal with this case. (And similarly
applied to the other lines.)

What do you mean "put down the info... with the git-archive?" Listing the
exact command?

Another thought I had on this - what kind of tags are we using?
Lightweight? Annotated? Signed?

I think 1.4.4 has been the only git release, and I used a lightweight tag
due to ignorance rather than choice.
On Fri, Jan 10, 2014 at 11:37 AM, Josh Elser <[EMAIL PROTECTED]> wrote:

> 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