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
