impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Robinson <he...@cloudera.com>
Subject Re: Ideas for organizing 3.0
Date Mon, 07 Nov 2016 23:51:54 GMT
How about "--enable-3.0-features" ?

On 5 November 2016 at 01:08, Marcel Kornacker <marcel@cloudera.com> wrote:

> dont-try-this-in-2dot8?
>
> On Fri, Nov 4, 2016 at 3:13 PM, Jim Apple <jbapple@cloudera.com> wrote:
> > Love it. What shall we call it?
> >
> > On Thu, Nov 3, 2016 at 10:22 PM, Henry Robinson <henry@cloudera.com>
> wrote:
> >> If possible, can we hide all compatibility-breaking features behind the
> >> *same* flag, so as to limit the combinatorial explosion of features
> turned
> >> on and off?
> >>
> >> On 3 November 2016 at 16:50, Daniel Hecht <dhecht@cloudera.com> wrote:
> >>
> >>> +1 for using flags to avoid branching too early, and then flipping the
> >>> defaults for 3.0 (and eventually removing the old code paths in/after
> >>> 3.0).  Of course, not everything can be handled this way, but many can.
> >>>
> >>> On Wed, Nov 2, 2016 at 5:21 PM, Jim Apple <jbapple@cloudera.com>
> wrote:
> >>>
> >>> > Does anyone else have any thoughts, ideas, or concerns?
> >>> >
> >>> > On Fri, Oct 28, 2016 at 10:04 AM, Jim Apple <jbapple@cloudera.com>
> >>> wrote:
> >>> > > 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?
> >>> > >>>
> >>> >
> >>>
> >>
> >>
> >>
> >> --
> >> Henry Robinson
> >> Software Engineer
> >> Cloudera
> >> 415-994-6679
>



-- 
Henry Robinson
Software Engineer
Cloudera
415-994-6679

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