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 <jes...@gmail.com> 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 <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. > > > > >> > > > > > >> > > > > > > > > > > > > > > >
