You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hive.apache.org by Owen O'Malley <om...@apache.org> on 2016/11/29 18:31:54 UTC
[DISCUSS] Making a stable release from branch 2
Hi all,
I'd like to volunteer as a Release Manager for making a stable feature
release from branch 2. However, rather than starting with master, I'll use
the 2.1 release and cherry pick fixes and features with a focus on a stable
release and picking features that have been tested at scale. Testing a Hive
release at scale is hard, time consuming, and resource intensive, but I
think that having a stable release with some of the great features that
we've put into Hive 2 will help drive adoption of the new branch.
Thanks,
Owen
Re: [DISCUSS] Making a stable release from branch 2
Posted by Sergey Shelukhin <se...@hortonworks.com>.
Hmm, I guess it makes sense if we interleave custom and master-based
releases. It may just create pain when backporting esp. given the branches
that do not share history. Also, after a master release all the subsequent
custom releases (other than dot releases in the previous custom releases)
must be supersets of that master-based release to avoid confusion (i.e. if
2.2 is custom, and 2.3 is off master, 2.4 cannot be a custom release based
off 2.2).
How do we define "waiting until master is completely stable”? Master is
not as stable as older version almost by definition. The usual approach
for conservative upgrade is to wait for the first dot release ;) Releasing
off master has not been a problem in the past.
On 16/11/29, 14:18, "Alan Gates" <al...@gmail.com> wrote:
>I’m not sure what would be confusing about the numbering. Assumably the
>next feature bearing release will be 2.2. The next one after that 2.3.
>We should make a rule that patches in version x don’t go away in x+1.
>With that I don’t see any confusion.
>
>I agree we shouldn’t turn master into a dumping ground that we never
>release off of (the way Hadoop has). I assume we will still make
>releases off of master in the future. I believe what Owen is proposing
>is a shorter path to a stable release, rather than waiting until master
>is completely stable. That makes sense to me.
>
>Alan.
>
>> On Nov 29, 2016, at 14:00, Sergey Shelukhin <se...@hortonworks.com>
>>wrote:
>>
>> We need to figure out the versioning strategy for this that is not
>> hopelessly confusing.
>> Also, having too many fixes in master as described is a different
>>problem,
>> of not releasing off master often enough.
>> What is to be done with master in this model?
>>
>> On 16/11/29, 12:37, "Sergio Pena" <se...@cloudera.com> wrote:
>>
>>> Good, thanks Owen for volunteering.
>>>
>>> I see we have too many bugfixes, features, and improvements on the
>>>master
>>> branch.
>>>
>>> A few questions:
>>>
>>> - How or what would be the process for cherry picking those fixes? How
>>> will
>>> you detect which ones are stable and which not?
>>>
>>> - What if others contributors want some patches to be added to the next
>>> release? How can we prove they're stable enough to be included?
>>>
>>> - How can the community help on making this new branch stable? Should
>>>we
>>> help on triaging, cherry-picking, testing, others ideas?
>>>
>>> I really agree we should be careful on doing the next feature release
>>> stable.
>>> Having hundred of new bugfixes and improvements on a branch makes
>>> difficult
>>> to validate its quality.
>>>
>>> - Sergio
>>>
>>>
>>> On Tue, Nov 29, 2016 at 12:31 PM, Owen O'Malley <om...@apache.org>
>>> wrote:
>>>
>>>> Hi all,
>>>> I'd like to volunteer as a Release Manager for making a stable
>>>> feature
>>>> release from branch 2. However, rather than starting with master, I'll
>>>> use
>>>> the 2.1 release and cherry pick fixes and features with a focus on a
>>>> stable
>>>> release and picking features that have been tested at scale. Testing a
>>>> Hive
>>>> release at scale is hard, time consuming, and resource intensive, but
>>>>I
>>>> think that having a stable release with some of the great features
>>>>that
>>>> we've put into Hive 2 will help drive adoption of the new branch.
>>>>
>>>> Thanks,
>>>> Owen
>>>>
>>
>
>
Re: [DISCUSS] Making a stable release from branch 2
Posted by Alan Gates <al...@gmail.com>.
I’m not sure what would be confusing about the numbering. Assumably the next feature bearing release will be 2.2. The next one after that 2.3. We should make a rule that patches in version x don’t go away in x+1. With that I don’t see any confusion.
I agree we shouldn’t turn master into a dumping ground that we never release off of (the way Hadoop has). I assume we will still make releases off of master in the future. I believe what Owen is proposing is a shorter path to a stable release, rather than waiting until master is completely stable. That makes sense to me.
Alan.
> On Nov 29, 2016, at 14:00, Sergey Shelukhin <se...@hortonworks.com> wrote:
>
> We need to figure out the versioning strategy for this that is not
> hopelessly confusing.
> Also, having too many fixes in master as described is a different problem,
> of not releasing off master often enough.
> What is to be done with master in this model?
>
> On 16/11/29, 12:37, "Sergio Pena" <se...@cloudera.com> wrote:
>
>> Good, thanks Owen for volunteering.
>>
>> I see we have too many bugfixes, features, and improvements on the master
>> branch.
>>
>> A few questions:
>>
>> - How or what would be the process for cherry picking those fixes? How
>> will
>> you detect which ones are stable and which not?
>>
>> - What if others contributors want some patches to be added to the next
>> release? How can we prove they're stable enough to be included?
>>
>> - How can the community help on making this new branch stable? Should we
>> help on triaging, cherry-picking, testing, others ideas?
>>
>> I really agree we should be careful on doing the next feature release
>> stable.
>> Having hundred of new bugfixes and improvements on a branch makes
>> difficult
>> to validate its quality.
>>
>> - Sergio
>>
>>
>> On Tue, Nov 29, 2016 at 12:31 PM, Owen O'Malley <om...@apache.org>
>> wrote:
>>
>>> Hi all,
>>> I'd like to volunteer as a Release Manager for making a stable
>>> feature
>>> release from branch 2. However, rather than starting with master, I'll
>>> use
>>> the 2.1 release and cherry pick fixes and features with a focus on a
>>> stable
>>> release and picking features that have been tested at scale. Testing a
>>> Hive
>>> release at scale is hard, time consuming, and resource intensive, but I
>>> think that having a stable release with some of the great features that
>>> we've put into Hive 2 will help drive adoption of the new branch.
>>>
>>> Thanks,
>>> Owen
>>>
>
Re: [DISCUSS] Making a stable release from branch 2
Posted by Sergey Shelukhin <se...@hortonworks.com>.
We need to figure out the versioning strategy for this that is not
hopelessly confusing.
Also, having too many fixes in master as described is a different problem,
of not releasing off master often enough.
What is to be done with master in this model?
On 16/11/29, 12:37, "Sergio Pena" <se...@cloudera.com> wrote:
>Good, thanks Owen for volunteering.
>
>I see we have too many bugfixes, features, and improvements on the master
>branch.
>
>A few questions:
>
>- How or what would be the process for cherry picking those fixes? How
>will
>you detect which ones are stable and which not?
>
>- What if others contributors want some patches to be added to the next
>release? How can we prove they're stable enough to be included?
>
>- How can the community help on making this new branch stable? Should we
>help on triaging, cherry-picking, testing, others ideas?
>
>I really agree we should be careful on doing the next feature release
>stable.
>Having hundred of new bugfixes and improvements on a branch makes
>difficult
>to validate its quality.
>
>- Sergio
>
>
>On Tue, Nov 29, 2016 at 12:31 PM, Owen O'Malley <om...@apache.org>
>wrote:
>
>> Hi all,
>> I'd like to volunteer as a Release Manager for making a stable
>>feature
>> release from branch 2. However, rather than starting with master, I'll
>>use
>> the 2.1 release and cherry pick fixes and features with a focus on a
>>stable
>> release and picking features that have been tested at scale. Testing a
>>Hive
>> release at scale is hard, time consuming, and resource intensive, but I
>> think that having a stable release with some of the great features that
>> we've put into Hive 2 will help drive adoption of the new branch.
>>
>> Thanks,
>> Owen
>>
Re: [DISCUSS] Making a stable release from branch 2
Posted by Sergio Pena <se...@cloudera.com>.
Good, thanks Owen for volunteering.
I see we have too many bugfixes, features, and improvements on the master
branch.
A few questions:
- How or what would be the process for cherry picking those fixes? How will
you detect which ones are stable and which not?
- What if others contributors want some patches to be added to the next
release? How can we prove they're stable enough to be included?
- How can the community help on making this new branch stable? Should we
help on triaging, cherry-picking, testing, others ideas?
I really agree we should be careful on doing the next feature release
stable.
Having hundred of new bugfixes and improvements on a branch makes difficult
to validate its quality.
- Sergio
On Tue, Nov 29, 2016 at 12:31 PM, Owen O'Malley <om...@apache.org> wrote:
> Hi all,
> I'd like to volunteer as a Release Manager for making a stable feature
> release from branch 2. However, rather than starting with master, I'll use
> the 2.1 release and cherry pick fixes and features with a focus on a stable
> release and picking features that have been tested at scale. Testing a Hive
> release at scale is hard, time consuming, and resource intensive, but I
> think that having a stable release with some of the great features that
> we've put into Hive 2 will help drive adoption of the new branch.
>
> Thanks,
> Owen
>