impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Hecht <dhe...@cloudera.com>
Subject Re: Ideas for organizing 3.0
Date Thu, 03 Nov 2016 23:50:43 GMT
+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?
> >>>
>

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