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