Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
http://gravatar.com/ctubbsii
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.

 
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB