Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: domain of josh.elser@gmail.com
 designates 209.85.216.180 as permitted sender)
Message-ID: <52F1C32C.6070708@gmail.com>
Date: Tue, 04 Feb 2014 23:50:52 -0500
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: [DISCUSS] How to generate RC's
References: 
 <CAFAMeYJi4jNzUCnZ_mfygm-UuTf8b71LZqqLchvHypVDJx4KKQ@mail.gmail.com>
 <52CE281A.3040402@gmail.com>
 <CAD-fFUJ=FZPZQ9CzFoyjaggpJA2vbEakuJWOGEUs8gDfe4MrSg@mail.gmail.com>
 <52D021C7.6050001@gmail.com>
 <CAFAMeY+p4y+dY2qW8x0S6+37UPXOiSfioGjQ=BAb5Mnx9BYtjg@mail.gmail.com>
 <52D4116E.7050707@gmail.com>
In-Reply-To: <52D4116E.7050707@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Some extra notes that I ran into with not working against 
maven-release-plugin.

The plugin will prompt for the release version, the tag name, and the 
next development version. For 1.5.1, we really want to give 1.5.1, 
1.5.1-rcN, 1.5.2-SNAPSHOT. However, this will result in 1.5.1-rcN being 
placed in the pom which is undesirable.

To get this to work, I actually gave 1.5.1, 1.5.1 and 1.5.2-SNAPSHOT 
(which results in the proper values in the pom), created the 1.5.1-rcN 
branch from the release plugin commit for 1.5.1, edited scm.tag in 
release.properties to be 1.5.1-rcN instead of 1.5.1, and then pushed the 
1.5.1-rcN branch. Then, release:perform will actually build and stage 
the right code.

Not as simple as it might be, but at least it works and semi-aligns with 
what we described originally.

On 1/13/14, 11:16 AM, Josh Elser wrote:
> 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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>