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 Thu, 06 Feb 2014 20:49:36 GMT
Changing the tagNameFormat would remove an extra manual step which is 
likely good. I'm not sure about how the local checkout stuff works and 
if there is something easier we can do there.

One extra thing that I've found that is a little awkward to work with 
now that we're in a vote, is that we almost want to freeze the 
1.5.1-SNAPSHOT branch. I haven't been able to come up with what we 
should do with the branch for the version we're trying to release 
considering that at least one RC will probably fail.

We *could* bump the 1.5.1-SNAPSHOT branch to 1.5.2-SNAPSHOT in the poms, 
but then we would need to revert that every time we fail a RC. That's 
probably the best solution that doesn't try to work around the 
maven-release-plugin, but it does leave some nice blemishes in the history.

On 2/5/14, 5:16 PM, Christopher wrote:
> We should change tagNameFormat for the maven-release-plugin to
> @{project.version}, so you can just hit "enter" at that field to
> accept the default. You may still need to do the rest of what you did
> (or something similar) to push to a different branch or tag, though...
> I'm not sure (I wonder if you could just let it build the local tag it
> creates instead of editing scm.tag), and simply don't push that tag
> until you change its name to one with -rcX.
> --
> Christopher L Tubbs II
> On Tue, Feb 4, 2014 at 11:50 PM, Josh Elser <> wrote:
>> 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 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 <>
>>>> wrote:
>>>>> For #1, we typically haven't had a need/desire to keep around how we
>>>>> 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
>>>>>> manifest for the hash? eww.) On the other hand, I can see a benefit
>>>>>> 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
>>>>>>>> when we
>>>>>>>> have something we are happy with. Thanks to Christopher and
>>>>>>>> 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
>>>>>>>> 3) Perform testing and voting as necessary
>>>>>>>> 3a) If the vote fails, make corrections and start over at
>>>>>>>> 4) After a vote passes, tag the release on the same commit
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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