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