accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [DISCUSS] How to generate RC's
Date Mon, 13 Jan 2014 16:16:46 GMT
On 1/13/14, 10:17 AM, Mike Drob wrote:
> #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?

Yes, e.g. run cmd1, then cmd2, then cmd3. Making a release (candidate) 
shouldn't be harder than ensuring you have a GPG created.

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

I think Christopher had recommended a signed tag. ACCUMULO-1468 should 
have that definitively, but I'm not really up to date on what 
common/good practices are here.

> 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 <josh.elser@gmail.com> 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 <josh.elser@gmail.com> 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
>>>>>
>>>>>
>>>>>
>>>
>>>
>

Mime
View raw message