accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] How to generate RC's
Date Fri, 07 Feb 2014 03:54:44 GMT
I say don't bump until the vote passes or fails. If it passes, either
drop the branch, or if there are commits since the RC was made, no-op
merge in the tag, bump the version, and rename the branch. The version
doesn't matter until later.

I believe the release plugin has a goal to bump versions only, so that
part is pretty easy.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Thu, Feb 6, 2014 at 3:49 PM, Josh Elser <josh.elser@gmail.com> wrote:
> 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
>> http://gravatar.com/ctubbsii
>>
>>
>> On Tue, Feb 4, 2014 at 11:50 PM, Josh Elser <josh.elser@gmail.com> 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 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>

Mime
View raw message