hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brock Noland <br...@cloudera.com>
Subject Re: 1.1 release (was Re: 0.15 release)
Date Wed, 28 Jan 2015 01:13:30 GMT
Hi,

As I mentioned before, my main concern was that the 1.0 release would block
the next release from trunk. Since we are in the RC phase for 1.0, this
doesn't seem likely. As such, I am ok with moving forward with the 1.x
naming scheme.

As such I have:

* Renamed "next" to "branch-1.1"
* Updated the release version on branch-1.1 to 1.1.0-SNAPSHOT
* Submitted a patch for trunk to update the version to 1.2.0-SNAPSHOT

I'd ask that items committed to trunk going forward use the fixVersion of
1.2.0. Additionally if you find blockers that you would like in 1.2, please
have them committed to trunk and ping me to merge them to 1.2.

Cheers,
Brock

On Mon, Jan 26, 2015 at 8:41 PM, Brock Noland <brock@cloudera.com> wrote:

> Hi Alan,
>
> Thank you very much for the clarification. Naming the branch "next" for
> now is fine with me. I've done so.
>
> Cheers,
> Brock
>
> On Mon, Jan 26, 2015 at 10:27 AM, Alan Gates <gates@hortonworks.com>
> wrote:
>
>> I'm not asking you to slow the work for the release.  If you want to
>> branch, you can branch.  What I'm asking is to hold on the numbering
>> scheme.  So you could name the branch 'next' or something and then rename
>> once we come to agreement.  Consensus in the community is important, and we
>> should avoid things that make that consensus harder.
>>
>> Alan.
>>
>>   Brock Noland <brock@cloudera.com>
>>  January 26, 2015 at 9:17
>> Hi Alan,
>>
>> In all of my experience at Apache, I have been encouraged to release.
>> Contributors rightly want to see their hard work gets in the hands of the
>> users. That's why they contribute after all. Many contributors who have
>> features in trunk would like get those features out into the community.
>> This is completely reasonable of them. After all they've invested
>> significant time in this work.
>>
>> Thus I don't feel we should delay getting their contributions released
>> while we debate 1.0. The two have nothing todo with each other. I've
>> mentioned on the list and in person to Thejas that I wanted this release
>> to
>> specifically avoid the 1.x discussion so it did not get bogged down in the
>> 1.x discussion. Again, this is completely reasonable.
>>
>> In short, everything I have experienced at Apache indicates that the folks
>> who want to release 0.15 should be free to do the work to make that
>> happen.
>>
>> Brock
>>
>>
>>   Alan Gates <gates@hortonworks.com>
>>  January 26, 2015 at 7:02
>>  Brock,
>>
>> Given there isn't consensus on numbering yet, could you holding off
>> making the 0.15 branch.  We should come to a conclusion on whether we're
>> doing 0.14.1/0.15 or 1.0/1.1 before assigning anymore numbers.
>>
>> Alan.
>>
>>   Brock Noland <brock@cloudera.com>
>>  January 20, 2015 at 21:25
>> Just a reminder that I plan on branching on 1/26/2015 and start
>> rolling release candidates on 2/9/2015. After branching I plan on
>> merging only blockers.
>>
>> Brock
>>   Brock Noland <brock@cloudera.com>
>>  January 12, 2015 at 14:37
>> Hi,
>>
>> Projects are instructed in the incubator that releases gain new users and
>> other attention. Additionally, as discussed in this forum I'd like to
>> increase the tempo of our release process[1].
>>
>> As such, I plan on following this process:
>>
>> 1) Provide two weeks notice of branching
>> 2) Provide two weeks to find issues on the branch and merging only
>> blockers
>> 3) Roll release candidates until a release vote passes
>>
>> As such I plan on branching on 1/26/2015 and start rolling release
>> candidates on 2/9/2015.
>>
>> Cheers,
>> Brock
>>
>> 1. Note I am not complaining as I did not help with releases until this
>> point.
>>
>>
>> CONFIDENTIALITY NOTICE
>> NOTICE: This message is intended for the use of the individual or entity
>> to which it is addressed and may contain information that is confidential,
>> privileged and exempt from disclosure under applicable law. If the reader
>> of this message is not the intended recipient, you are hereby notified that
>> any printing, copying, dissemination, distribution, disclosure or
>> forwarding of this communication is strictly prohibited. If you have
>> received this communication in error, please contact the sender immediately
>> and delete it from your system. Thank You.
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message