I agree with your proposal. I especially like the idea of updating master to be 3.x and cherry-picking all changes that are compatible with 2.x to the 2.x branch (as opposed to having master continue to be 2.x).
I look forward to this proposal being implemented, because I am working on some compatibility breaking changes related to Decimal. On Wed, Jan 10, 2018 at 2:36 PM, Philip Zeyliger <[email protected]> wrote: > Hi folks, > > I'd like to start the conversation around 3.0, spurred in part by some > compatibility-challenging issues. I'm leading with a somewhat concrete > proposal, but that's meant to start the discussion! > > Impala's master branch currently self-identifies as version 2.11. (See > https://github.com/apache/impala/blob/master/bin/save-version.sh). There's > a queue of changes that have enough compatibility concerns that we've been > postponing them. (For example, see "Reserving standard SQL keywords next > Impala release" in this mailing list.) > > I propose we create a 2.x branch, and update master to be 3.0, thereby > indicating that we'd accept changes with compatibility concerns in master. > Both master and 2.x would be active, and, at least for the beginning, > changes would automatically be pulled into the 2.x line, unless explicitly > blacklisted. After a while, of course, there would be 3.x releases, and 2.x > releases would slow down. > > I've gone through labels IN ("incompatibility", "compatibility") and > resolution = "Unresolved" and project=impala > <https://issues.apache.org/jira/issues/?jql=labels%20IN% > 20(%22incompatibility%22%2C%20%22compatibility%22)%20% > 20and%20resolution%20%3D%20%22Unresolved%22%20and%20project%3Dimpala> > in > JIRA and here's a short, curated sublist: > > > JIRA > > Summary > > Comment > > IMPALA-4277 > > > Impala should build against latest Hadoop components > > Strive to make running both possible. > > IMPALA-3916 > > Reserve SQL:2016 keywords > > See thread "Reserving standard SQL keywords next Impala release > (IMPALA-3916)" on the mailing lists. > > IMPALA-6204 > > Remove DataSourceScanNode at next compatibility breaking point > > > IMPALA-4924 > > Remove DECIMAL V1 code at next compatibility breaking version > > Probably switch to DECIMAL_V2 by default, but retain option. > > IMPALA-4319 > > Remove unused query options in compat-breaking version > > > IMPALA-4306 > > Remove deprecated query options at compatibility-breaking version > > > > Creating a new branch has the drawback of yet another entity to think about > (and cherrypick to), but it seems like we need it to provide a place for > changes like those above to land. > > Thoughts? > > Thanks! > > -- Philip >
