Thank you for starting the discussion. It would be great to have a branch to start including non-compatible changes. I would like to propose adding two Jiras that switch default options / behaviors
* IMPALA-5037 <https://issues.apache.org/jira/browse/IMPALA-5037> (Change default Parquet array resolution according to Parquet standard.) * IMPALA-5293 <https://issues.apache.org/jira/browse/IMPALA-5293> (Perform clustering before insert by default) and Should we start tagging all candidates with a common label, e.g. include-in-v3? Cheers, Lars On Wed, Jan 10, 2018 at 11:50 PM, Taras Bobrovytsky <[email protected]> wrote: > 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 > > >
