Can you elaborate on the maintenance required if there were a feature flag?
On Wed, Jun 13, 2018 at 9:05 AM, Attila Jeges <[email protected]> wrote: > I agree with Quanlong that we can mark 3.0 as experimental and introduce > IMPALA-3307 in 3.1. > > Adding a feature flag to switch back and forth between the legacy timezone > names and the new timezone names is certainly possible, although I think > maintaining and testing the flag would be too much of a trouble. > > To help users who want to keep the old timezone names, we can create a > config file that contains the definitions for all the legacy names and link > it from the online documentation. Users then can download the config file > and add the legacy names to Impala with the --hdfs_zone_alias_conf flag. > > On Wed, Jun 13, 2018 at 6:51 AM, Quanlong Huang <[email protected]> > wrote: > > > The problem is that we've released 3.0, otherwise, we can just add it in > > 3.0 branch. > > > > > > From the user perspective, I agree with merging it with feature flags in > > 3.x, though I agree with "Breaking changes must bump the major version". > I > > believe no one in the industry has deployed impala-3.0 in production, so > > actually, if we add it in 3.1, no one is broke. We can mark that 3.0 is > > experimental and not recommended to use when we release 3.1. In the other > > side, if hopefully this feature has a workaround or feature flag, it > > shouldn't be considered as "breaking". > > > > > > It's too early to have a 4.x branch. I can't imagine that we maintain > 2.x, > > 3.x, 4.x and maybe 5.x (for future breaking changes) together when the > > majority of the community is still using 2.x branch. > > Quanlong > > > > > > At 2018-06-13 06:04:10, "Philip Zeyliger" <[email protected]> wrote: > > >On Mon, Jun 11, 2018 at 2:49 PM Jim Apple <[email protected]> wrote: > > > > > >> Phil, if Jeszy's solution is possible (feature flag, off by default in > > the > > >> 3.x line), would that align with your preference? > > >> > > > > > >I'd be fine with "feature flag, 3.x." I'd also be fine with "no feature > > >flag, 3.x" and "4.x". > > > > > >-- Philip > > > > > > > > >> On Mon, Jun 11, 2018 at 2:29 PM, Taras Bobrovytsky < > [email protected] > > > > > >> wrote: > > >> > > >> > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[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. > > >> > > > > > >> > > > >> > > > > > >> > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >
