impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Apple <jbap...@cloudera.com>
Subject Re: Ideas for organizing 3.0
Date Fri, 28 Oct 2016 17:04:57 GMT
I like this idea a lot.

On Fri, Oct 28, 2016 at 10:01 AM, Tim Armstrong <tarmstrong@cloudera.com> wrote:
> I think we should also have a period leading up to the branching where we
> can add incompatible changes guarded by flags. I think otherwise it will be
> a headache trying to stage things (realistically some
> compatibility-breaking changes will be ready early and we don't want to
> have them sitting off to the side bit-rotting).
>
> One case is getting Impala to work against the latest Hadoop/Hive/HBase
> APIs - there were incompatible changes but it would be great to have master
> buildable against both versions.
>
> On Fri, Oct 28, 2016 at 9:51 AM, Jim Apple <jbapple@cloudera.com> wrote:
>
>> The most recent release was 2.7.0. We have 32 issues that we might
>> want to tackle for 3.0:
>>
>> https://issues.cloudera.org/issues/?filter=11830
>>
>> Does anyone have any thoughts about how to organize this? For instance
>> we might decide:
>>
>> 0. Starting immediately, the community is encouraged to submit issues
>> that would break compatibility. Detailed designs are also encouraged.
>>
>> 1. After 2.9.0, commits that break compatibility will be allowed in
>> the "master" branch.
>>
>> 2. After 2.9.0 a call will go out for anyone who wants to get a
>> compatibility-breaking patch in that they have 3 months to do so.
>>
>> 3. After three months, we'll cut a new release candidate and bump all
>> JIRA issues that would break compatibility to Target Version: Impala
>> 4.0
>>
>> Thoughts?
>>

Mime
View raw message