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
