I started some work on supporting both old and new HBase/Hive/HDFS APIs, but I think that's kind-of a separate issue.
I'd be excited to start working on some of the changes (particularly simplifying some of the implicit casting behaviour). On Mon, Nov 28, 2016 at 9:05 AM, Jim Apple <[email protected]> wrote: > Sounds good. Has anyone started work on any compat-breaking changes > that could go under this flag? > > On Mon, Nov 7, 2016 at 3:51 PM, Henry Robinson <[email protected]> wrote: > > How about "--enable-3.0-features" ? > > > > On 5 November 2016 at 01:08, Marcel Kornacker <[email protected]> > wrote: > > > >> dont-try-this-in-2dot8? > >> > >> On Fri, Nov 4, 2016 at 3:13 PM, Jim Apple <[email protected]> wrote: > >> > Love it. What shall we call it? > >> > > >> > On Thu, Nov 3, 2016 at 10:22 PM, Henry Robinson <[email protected]> > >> 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 <[email protected]> > 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 <[email protected]> > >> wrote: > >> >>> > >> >>> > Does anyone else have any thoughts, ideas, or concerns? > >> >>> > > >> >>> > On Fri, Oct 28, 2016 at 10:04 AM, Jim Apple <[email protected] > > > >> >>> wrote: > >> >>> > > I like this idea a lot. > >> >>> > > > >> >>> > > On Fri, Oct 28, 2016 at 10:01 AM, Tim Armstrong < > >> >>> [email protected]> > >> >>> > 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 < > [email protected]> > >> >>> > 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 >
