>Csaba, is that possible with th change similar to how it is now, or would >it have to be rewritten?
Keeping the old implementation and switching with flag: It is Attila's change, so he knows best the cost of keeping the old solution. I think that is not impossible to do this, but some parts would have to be rewritten. I am especially worried about testing: there are already 2 flags that affect timestamp handling in the backend (use_local_tz_for_unix_ timestamp_conversions, convert_legacy_hive_parquet_utc_timestamps), and a flag that switches between the timezone implementations would interact with both of them, so a lot of tests would have to be duplicated to give a good coverage. The new timezone db makes it possible to add timezone aliases in a text file, so it may be possible to add all the current timezone names by default. This still wouldn't be a perfect solution, because lot of the current aliases are ambiguous or wrong, so I would prefer to remove them by default. On Mon, Jun 11, 2018 at 11: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? > > 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. > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
