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
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
On Thu, Feb 6, 2014 at 3:49 PM, Josh Elser <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.