I agree with Quanlong that we can mark 3.0 as experimental and introduce IMPALA-3307 in 3.1.
Adding a feature flag to switch back and forth between the legacy timezone names and the new timezone names is certainly possible, although I think maintaining and testing the flag would be too much of a trouble. To help users who want to keep the old timezone names, we can create a config file that contains the definitions for all the legacy names and link it from the online documentation. Users then can download the config file and add the legacy names to Impala with the --hdfs_zone_alias_conf flag. On Wed, Jun 13, 2018 at 6:51 AM, Quanlong Huang <[email protected]> wrote: > The problem is that we've released 3.0, otherwise, we can just add it in > 3.0 branch. > > > From the user perspective, I agree with merging it with feature flags in > 3.x, though I agree with "Breaking changes must bump the major version". I > believe no one in the industry has deployed impala-3.0 in production, so > actually, if we add it in 3.1, no one is broke. We can mark that 3.0 is > experimental and not recommended to use when we release 3.1. In the other > side, if hopefully this feature has a workaround or feature flag, it > shouldn't be considered as "breaking". > > > It's too early to have a 4.x branch. I can't imagine that we maintain 2.x, > 3.x, 4.x and maybe 5.x (for future breaking changes) together when the > majority of the community is still using 2.x branch. > Quanlong > > > At 2018-06-13 06:04:10, "Philip Zeyliger" <[email protected]> wrote: > >On Mon, Jun 11, 2018 at 2:49 PM Jim Apple <[email protected]> wrote: > > > >> Phil, if Jeszy's solution is possible (feature flag, off by default in > the > >> 3.x line), would that align with your preference? > >> > > > >I'd be fine with "feature flag, 3.x." I'd also be fine with "no feature > >flag, 3.x" and "4.x". > > > >-- Philip > > > > > >> On Mon, Jun 11, 2018 at 2:29 PM, Taras Bobrovytsky <[email protected] > > > >> wrote: > >> > >> > I agree with Jim. It would be better to bump to 4.0 in my opinion. We > >> > should follow the simple rule: Breaking changes must bump the major > >> version > >> > number. > >> > > >> > On Mon, Jun 11, 2018 at 2:17 PM, Jeszy <[email protected]> wrote: > >> > > >> > > My assumption was that the workaround Phil mentioned must be simple > to > >> > > toggle (e.g. flag). If it's not, it probably shouldn't be > considered a > >> > > viable workaround. > >> > > > >> > > On 11 June 2018 at 10:42, Jim Apple <[email protected]> wrote: > >> > > > >> > > > Csaba, is that possible with th change similar to how it is now, > or > >> > would > >> > > > it have to be rewritten? > >> > > > > >> > > > On Mon, Jun 11, 2018 at 1:30 AM Jeszy <[email protected]> wrote: > >> > > > > >> > > > > I think we should include it in 3.1, with the feature disabled > by > >> > > default > >> > > > > (to not break on a minor upgrade), but recommend enabling it in > >> docs > >> > > and > >> > > > > make it enabled by default in 4.0. > >> > > > > > >> > > > > On 11 June 2018 at 10:23, Jim Apple <[email protected]> > wrote: > >> > > > > > >> > > > > > Any more thoughts? This question is for everyone in the Impala > >> > > > community. > >> > > > > > > >> > > > > > Right now the plan is to fold it into 3.1, with two to one in > >> favor > >> > > of > >> > > > > that > >> > > > > > over bumping to 4.0. > >> > > > > > > >> > > > > > On Mon, Jun 4, 2018 at 8:48 PM Jim Apple < > [email protected]> > >> > > wrote: > >> > > > > > > >> > > > > > > I am more in favor of bumping to 4.0. It is a rapid > escalation, > >> > but > >> > > > we > >> > > > > > > wouldn’t be the first open source project to switch to a > model > >> > with > >> > > > > Short > >> > > > > > > major versions, as both Clang and Firefox have done so. > >> > > > > > > > >> > > > > > > I also feel that, both from a semver perspective and as a > user > >> of > >> > > > other > >> > > > > > > software, I expect breaking changes to bump the major > version > >> > > number. > >> > > > > > > > >> > > > > > > That said, this is not a hill I’m trying to die on. My > focus is > >> > on > >> > > > the > >> > > > > > > user experience, and if our users end up well informed of > the > >> > > > > breakages, > >> > > > > > > then I will feel we have done our job, no matter what > version > >> > > number > >> > > > we > >> > > > > > > stamp on it. > >> > > > > > > > >> > > > > > > On Mon, Jun 4, 2018 at 7:57 PM Philip Zeyliger < > >> > > [email protected]> > >> > > > > > > wrote: > >> > > > > > > > >> > > > > > >> Hi Csaba! > >> > > > > > >> > >> > > > > > >> I would be fine with both proposals, with a slight > preference > >> to > >> > > B. > >> > > > My > >> > > > > > >> understanding is that you're going to expose a way to > define > >> > > > overrides > >> > > > > > for > >> > > > > > >> time zone definitions, so there will be pretty workable > >> > > workarounds > >> > > > > too. > >> > > > > > >> > >> > > > > > >> -- Philip > >> > > > > > >> > >> > > > > > >> On Mon, Jun 4, 2018 at 1:45 PM, Csaba Ringhofer < > >> > > > > > [email protected] > >> > > > > > >> > > >> > > > > > >> wrote: > >> > > > > > >> > >> > > > > > >> > Hi Folks! > >> > > > > > >> > > >> > > > > > >> > We had a discussion with a few people about the > versioning > >> of > >> > > > > Impala > >> > > > > > >> after > >> > > > > > >> > 3.0. The motivation was that IMPALA-3307 (which replaces > the > >> > > > > timezone > >> > > > > > >> > implementation in Impala, and contains some breaking > >> changes) > >> > > > missed > >> > > > > > 3.0 > >> > > > > > >> > and we are not sure about the version in which it can be > >> > > released > >> > > > - > >> > > > > is > >> > > > > > >> it > >> > > > > > >> > 3.1 or 4.0? > >> > > > > > >> > > >> > > > > > >> > A. jumping to 4.0 would communicate clearly that the > release > >> > > > > contains > >> > > > > > >> > braking changes - if the plan for Impala is to follow > >> semantic > >> > > > > > >> versioning, > >> > > > > > >> > than this is the way to go > >> > > > > > >> > > >> > > > > > >> > B. releasing it in 3.1 would communicate that the change > is > >> > too > >> > > > > small > >> > > > > > >> for a > >> > > > > > >> > major version bump, and major versions are kept for BIG > >> > changes > >> > > in > >> > > > > > >> Impala > >> > > > > > >> > > >> > > > > > >> > My personal preference is for B - if a breaking change is > >> > > > relatively > >> > > > > > >> small > >> > > > > > >> > and workarounds are possible + the community agrees, > then it > >> > > > should > >> > > > > be > >> > > > > > >> > possible to release it in minor a version, while major > >> > versions > >> > > > > could > >> > > > > > be > >> > > > > > >> > kept for changes where switching Impala version needs > large > >> > > effort > >> > > > > on > >> > > > > > >> the > >> > > > > > >> > user's side (for example 2->3 jump needs new Java and > Hadoop > >> > > major > >> > > > > > >> > version), or when a huge improvement is added to Impala > >> which > >> > > > > deserves > >> > > > > > >> > extra attention. This is more of an aesthetic than a > >> rational > >> > > > choice > >> > > > > > on > >> > > > > > >> my > >> > > > > > >> > side, so I am totally ok with semantic versioning too, if > >> the > >> > > > > > community > >> > > > > > >> > prefers it. > >> > > > > > >> > > >> > > > > > >> > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> >
