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
