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 <jbap...@cloudera.com> 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 <jes...@gmail.com> 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 <jbap...@cloudera.com> 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 <jbap...@cloudera.com> 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 <phi...@cloudera.com> > > > > 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 < > > > csringho...@cloudera.com > > > >> > > > > >> 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. > > > >> > > > > >> > > > > > > > > > >
