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