hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Shelukhin <>
Subject Re: [DISCUSS] Making a stable release from branch 2
Date Tue, 29 Nov 2016 23:34:34 GMT
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" <> 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.
>> On Nov 29, 2016, at 14:00, Sergey Shelukhin <>
>> 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
>> 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" <> wrote:
>>> Good, thanks Owen for volunteering.
>>> I see we have too many bugfixes, features, and improvements on the
>>> 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
>>> 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 <>
>>> 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
>>>> think that having a stable release with some of the great features
>>>> we've put into Hive 2 will help drive adoption of the new branch.
>>>> Thanks,
>>>>   Owen

View raw message