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