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
