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
