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. > > >> > > > >> > > > > > >
