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? >>>
