You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@impala.apache.org by Csaba Ringhofer <cs...@cloudera.com> on 2018/06/04 20:45:43 UTC
Breaking changes after 3.0, versioning, IMPALA-3307
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.
Re: Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Attila Jeges <at...@cloudera.com.INVALID>.
If we want to implement the feature flag, we need to figure out how to map
the old timezone names to the IANA names.
The timezone mappings that are in use in 3.0 are not always sensible and
sometimes they are downright misleading. This stems from the issues
surrounding the current implementation of the timezone lookup function
(TimezoneDatabase::FindTimezone()). These issues are described in detail in
IMPALA-5563.
For instance, the lookup function currently interprets "CEST" as an alias
for "Africa/Ceuta". Since "CEST" stands for "Central European Summer Time",
I imagine users would expect to get "CET" ("Central Europian Time")
timezone or the timezone of some Central European city instead (e.g.
Europe/Paris or Europe/Budapest). Note, that although all these timezones
use the same DST offset they are different timezones with different rules.
So which mapping should we use when the feature flag is set? I don't think
there is a good answer here. Whichever mapping we choose, chances are users
won't be happy with it and we would have to change it later.
In summary. instead of trying to hard-code the 3.0 mappings (including the
ambiguous/misleading ones) under a feature flag, I think it would make more
sense to provide users with a config file that contains most legacy
timezone names with some sensible mappings. Users can start with that and
then remove/add/modify timezone mappings as they see fit. I think this way
we could avoid a lot of confusion
On Wed, Jun 13, 2018 at 8:03 PM, Jim Apple <jb...@cloudera.com.invalid>
wrote:
> Can you elaborate on the maintenance required if there were a feature flag?
>
> On Wed, Jun 13, 2018 at 9:05 AM, Attila Jeges <at...@cloudera.com>
> 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 <hu...@126.com>
> > 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" <ph...@cloudera.com> wrote:
> > > >On Mon, Jun 11, 2018 at 2:49 PM Jim Apple <jb...@cloudera.com>
> 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 <
> > tarasbob@apache.org
> > > >
> > > >> 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 <je...@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 <jb...@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 <je...@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 <jb...@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 <
> > > jbapple@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 <
> > > >> > > philip@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 <
> > > >> > > > > > csringhofer@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.
> > > >> > > > > > >> >
> > > >> > > > > > >>
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>
Re: Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Jim Apple <jb...@cloudera.com.INVALID>.
Can you elaborate on the maintenance required if there were a feature flag?
On Wed, Jun 13, 2018 at 9:05 AM, Attila Jeges <at...@cloudera.com> 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 <hu...@126.com>
> 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" <ph...@cloudera.com> wrote:
> > >On Mon, Jun 11, 2018 at 2:49 PM Jim Apple <jb...@cloudera.com> 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 <
> tarasbob@apache.org
> > >
> > >> 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 <je...@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 <jb...@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 <je...@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 <jb...@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 <
> > jbapple@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 <
> > >> > > philip@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 <
> > >> > > > > > csringhofer@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.
> > >> > > > > > >> >
> > >> > > > > > >>
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>
Re: Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Attila Jeges <at...@cloudera.com>.
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 <hu...@126.com>
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" <ph...@cloudera.com> wrote:
> >On Mon, Jun 11, 2018 at 2:49 PM Jim Apple <jb...@cloudera.com> 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 <tarasbob@apache.org
> >
> >> 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 <je...@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 <jb...@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 <je...@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 <jb...@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 <
> jbapple@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 <
> >> > > philip@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 <
> >> > > > > > csringhofer@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.
> >> > > > > > >> >
> >> > > > > > >>
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
Re:Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Quanlong Huang <hu...@126.com>.
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" <ph...@cloudera.com> wrote:
>On Mon, Jun 11, 2018 at 2:49 PM Jim Apple <jb...@cloudera.com> 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 <ta...@apache.org>
>> 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 <je...@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 <jb...@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 <je...@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 <jb...@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 <jb...@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 <
>> > > philip@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 <
>> > > > > > csringhofer@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.
>> > > > > > >> >
>> > > > > > >>
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Philip Zeyliger <ph...@cloudera.com>.
On Mon, Jun 11, 2018 at 2:49 PM Jim Apple <jb...@cloudera.com> 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 <ta...@apache.org>
> 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 <je...@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 <jb...@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 <je...@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 <jb...@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 <jb...@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 <
> > > philip@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 <
> > > > > > csringhofer@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.
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Csaba Ringhofer <cs...@cloudera.com>.
>Csaba, is that possible with th change similar to how it is now, or would
>it have to be rewritten?
Keeping the old implementation and switching with flag:
It is Attila's change, so he knows best the cost of keeping the old
solution. I think that is not impossible to do this, but some parts would
have to be rewritten.
I am especially worried about testing: there are already 2 flags that
affect timestamp handling in the backend (use_local_tz_for_unix_
timestamp_conversions, convert_legacy_hive_parquet_utc_timestamps), and a
flag that switches between the timezone implementations would interact with
both of them, so a lot of tests would have to be duplicated to give a good
coverage.
The new timezone db makes it possible to add timezone aliases in a text
file, so it may be possible to add all the current timezone names by
default. This still wouldn't be a perfect solution, because lot of the
current aliases are ambiguous or wrong, so I would prefer to remove them by
default.
On Mon, Jun 11, 2018 at 11:49 PM, Jim Apple <jb...@cloudera.com> wrote:
> Phil, if Jeszy's solution is possible (feature flag, off by default in the
> 3.x line), would that align with your preference?
>
> On Mon, Jun 11, 2018 at 2:29 PM, Taras Bobrovytsky <ta...@apache.org>
> 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 <je...@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 <jb...@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 <je...@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 <jb...@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 <jb...@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 <
> > > philip@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 <
> > > > > > csringhofer@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.
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Jim Apple <jb...@cloudera.com>.
Phil, if Jeszy's solution is possible (feature flag, off by default in the
3.x line), would that align with your preference?
On Mon, Jun 11, 2018 at 2:29 PM, Taras Bobrovytsky <ta...@apache.org>
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 <je...@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 <jb...@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 <je...@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 <jb...@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 <jb...@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 <
> > philip@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 <
> > > > > csringhofer@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.
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Taras Bobrovytsky <ta...@apache.org>.
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 <je...@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 <jb...@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 <je...@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 <jb...@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 <jb...@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 <
> philip@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 <
> > > > csringhofer@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.
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Jeszy <je...@gmail.com>.
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 <jb...@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 <je...@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 <jb...@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 <jb...@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 <ph...@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 <
> > > csringhofer@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.
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Jim Apple <jb...@cloudera.com>.
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 <je...@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 <jb...@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 <jb...@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 <ph...@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 <
> > csringhofer@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.
> > >> >
> > >>
> > >
> >
>
Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Jeszy <je...@gmail.com>.
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 <jb...@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 <jb...@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 <ph...@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 <
> csringhofer@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.
> >> >
> >>
> >
>
Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Jim Apple <jb...@cloudera.com>.
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 <jb...@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 <ph...@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 <csringhofer@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.
>> >
>>
>
Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Jim Apple <jb...@cloudera.com>.
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 <ph...@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 <cs...@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.
> >
>
Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Philip Zeyliger <ph...@cloudera.com>.
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 <cs...@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.
>
2.6, was Re: Breaking changes after 3.0, versioning, IMPALA-3307
Posted by Jim Apple <jb...@cloudera.com>.
周胜为, I don’t understand exactly what the issue is or how it relates to time
zones. Can you elaborate?
On Mon, Jun 4, 2018 at 6:00 PM 周胜为 <86...@qq.com> wrote:
> I use impala version is 2.6. I just can not get StringVal value, but can
> get BigintVal value------------------ 原始邮件 ------------------
> 发件人: "Csaba Ringhofer"<cs...@cloudera.com>
> 发送时间: 2018年6月5日(星期二) 凌晨4:45
> 收件人: "dev"<de...@impala.apache.org>;
> 主题: Breaking changes after 3.0, versioning, IMPALA-3307
>
>
> 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.
回复：Breaking changes after 3.0, versioning, IMPALA-3307
Posted by 周胜为 <86...@qq.com>.
I use impala version is 2.6. I just can not get StringVal value, but can get BigintVal value------------------ 原始邮件 ------------------
发件人: "Csaba Ringhofer"<cs...@cloudera.com>
发送时间: 2018年6月5日(星期二) 凌晨4:45
收件人: "dev"<de...@impala.apache.org>;
主题: Breaking changes after 3.0, versioning, IMPALA-3307
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.