Re: [DISCUSS] breaking changes in 2.x

[Bobby Evans]

Windows remains perpetually backwards compatible.  Even to the point that 
windows ships with older broken versions of internal libraries so if it detects 
specific software and load up the old version as needed. 

Mac usually provides an upgrade path and will allow apps using up to date APIs 
from the previous version of the OS to run on the new version unchanged. But if 
you are using a deprecated API you have to change before the next version is 
released of you will be in trouble, and even some non-deprecated APIs can 
change at a moments notice.
The Linux kernel maintains strict compatibility with user space like windows, 
which is why docker can work, but with break kernel modules without too much 
concern.  The GNU user space, however breaks binary compatibility between 
releases all the time, but maintains source compatibility (just recompile).
Hadoop will break things between major releases but not between minor releases. 
 There is no guarantee of a rolling upgrade between major releases.  Which is 
partly why they are just starting to move towards 3.x and have multiple 
different flavors of 2.x lines alive.
And then there is guava where they just don't care.

There are pros and cons to all of these.  I thought initially that we had 
agreed on a model like Hadoop, although truthfully I don't think we ever 
formalized any of that, and that is why I started this chain.  I really see 
value, however, in the Mac model.  And since I can maintain compatibility, but 
it is a little painful to do so, I will try to do that. Right now, honestly, I 
think 2.x could be a rolling upgrade from 1.x, so I will try to maintain that.  
We may hit a feature where it just will not be possible to do that, but we 
should discuss that when it happens.

- Bobby

On Thursday, November 10, 2016, 3:06:41 AM CST, Kyle Nusbaum 
 wrote:On Wednesday, November 9, 2016, 7:23:09 
AM CST, Harsha Chintalapani  wrote:> If we want users to 
upgrade to new version, the rolling upgrade is a major
> decision factor. As a community, we need to look API updates or breaking
> changes much more diligently.
Within a major version, I agree. APIs should be as stable as possible within a 
version release.

> I agree to an extent we shouldn't limiting ourselves with rolling upgrade.
> But having announced rolling-upgrade in 0.10 and then not supporting it in
> 1.x and now in 2.x. In User's point of view, Storm is not rolling
> upgradable although we shipped a release stating that rolling upgrade is
> supported and in follow-up release we taken that off.
The user would be correct. Storm would not be rolling-upgradable *between major 
versions.*I don't see how it's possible to develop and improve a project if it 
must remain perpetually backwards compatible, so I think it's necessary to 
reject compatibility as a *primary* goal.
Eventually (hopefully) we'll arrive at an API that we're happy with that we 
don't feel like we need to change.Then we can claim rolling upgrades across 
major version numbers.

> Does these API changes are critical and worth breaking rolling upgrade?
My position is that we don't want to limit ourselves to "critical" API changes. 
This will stick us with an inferior API that we can't evolve.It's accepting the 
long-term pain of inconsistent API or old baggage to avoid the short-term pain 
of relaunching or updating topologies when you do a major version upgrade.
Storm is not at the place in its life where it has stopped evolving, and I 
don't want to stifle its development.

Re: [DISCUSS] breaking changes in 2.x

[Harsha Chintalapani]

Why don't we start introducing protocol versions in thrift API. This way a
old supervisor can still communicate by providing a older version and new
nimbus can handle both protocols. API changes doesn't necessarily mean
we've to break the older API. If the existing users doesn't have good
upgrade path there will less uses on the new version.
Critical API changes can still be possible by versioning the API.
-Harsha

On Thu, Nov 10, 2016 at 7:06 AM Kyle Nusbaum 
wrote:

> On Wednesday, November 9, 2016, 7:23:09 AM CST, Harsha Chintalapani <
> st...@harsha.io> wrote:> If we want users to upgrade to new version, the
> rolling upgrade is a major
> > decision factor. As a community, we need to look API updates or breaking
> > changes much more diligently.
> Within a major version, I agree. APIs should be as stable as possible
> within a version release.
>
> > I agree to an extent we shouldn't limiting ourselves with rolling
> upgrade.
> > But having announced rolling-upgrade in 0.10 and then not supporting it
> in
> > 1.x and now in 2.x. In User's point of view, Storm is not rolling
> > upgradable although we shipped a release stating that rolling upgrade is
> > supported and in follow-up release we taken that off.
> The user would be correct. Storm would not be rolling-upgradable *between
> major versions.*I don't see how it's possible to develop and improve a
> project if it must remain perpetually backwards compatible, so I think it's
> necessary to reject compatibility as a *primary* goal.
> Eventually (hopefully) we'll arrive at an API that we're happy with that
> we don't feel like we need to change.Then we can claim rolling upgrades
> across major version numbers.
>
> > Does these API changes are critical and worth breaking rolling upgrade?
> My position is that we don't want to limit ourselves to "critical" API
> changes. This will stick us with an inferior API that we can't evolve.It's
> accepting the long-term pain of inconsistent API or old baggage to avoid
> the short-term pain of relaunching or updating topologies when you do a
> major version upgrade.
> Storm is not at the place in its life where it has stopped evolving, and I
> don't want to stifle its development.
>

Re: [DISCUSS] breaking changes in 2.x

[Kyle Nusbaum]

On Wednesday, November 9, 2016, 7:23:09 AM CST, Harsha Chintalapani 
 wrote:> If we want users to upgrade to new version, the 
rolling upgrade is a major
> decision factor. As a community, we need to look API updates or breaking
> changes much more diligently.
Within a major version, I agree. APIs should be as stable as possible within a 
version release.

> I agree to an extent we shouldn't limiting ourselves with rolling upgrade.
> But having announced rolling-upgrade in 0.10 and then not supporting it in
> 1.x and now in 2.x. In User's point of view, Storm is not rolling
> upgradable although we shipped a release stating that rolling upgrade is
> supported and in follow-up release we taken that off.
The user would be correct. Storm would not be rolling-upgradable *between major 
versions.*I don't see how it's possible to develop and improve a project if it 
must remain perpetually backwards compatible, so I think it's necessary to 
reject compatibility as a *primary* goal.
Eventually (hopefully) we'll arrive at an API that we're happy with that we 
don't feel like we need to change.Then we can claim rolling upgrades across 
major version numbers.

> Does these API changes are critical and worth breaking rolling upgrade?
My position is that we don't want to limit ourselves to "critical" API changes. 
This will stick us with an inferior API that we can't evolve.It's accepting the 
long-term pain of inconsistent API or old baggage to avoid the short-term pain 
of relaunching or updating topologies when you do a major version upgrade.
Storm is not at the place in its life where it has stopped evolving, and I 
don't want to stifle its development.

Re: [DISCUSS] breaking changes in 2.x

[Harsha Chintalapani]

If we want users to upgrade to new version, the rolling upgrade is a major
decision factor. As a community, we need to look API updates or breaking
changes much more diligently.
I agree to an extent we shouldn't limiting ourselves with rolling upgrade.
But having announced rolling-upgrade in 0.10 and then not supporting it in
1.x and now in 2.x. In User's point of view, Storm is not rolling
upgradable although we shipped a release stating that rolling upgrade is
supported and in follow-up release we taken that off.
Does these API changes are critical and worth breaking rolling upgrade?

-Harsha

On Mon, Nov 7, 2016 at 9:16 AM Kyle Nusbaum 
wrote:

I worry that making it a priority to have rolling upgrades between major
versions significantly restricts the kinds of changes that we can make,
including some kinds of changes that a major version increment is supposed
to mark. I'm not really in support of trying to do that.
If we can't make changes that break compatibility now, when can we make
them? Can changes like that ever be made? I don't know that it's good to
limit ourselves like that.
Trying to accommodate rolling upgrades is a good idea, but I'm not sure
about rejecting code changes across major versions to support them. 2.x
represents a large shift in the project, and I expect once the translation,
etc. is done, things will calm down and APIs will become more stable,
allowing more of our future releases to be rolling even across major
versions. I'd rather get these kinds of changes out of the way now in the
2.x release than cart along the vestiges of 1.x from now on.
What do others think about this?
-- Kyle

On Monday, November 7, 2016, 3:10:08 AM CST, Bobby Evans
 wrote:Let's distinguish between wire
compatibility changes and API compatibility changes, along with impact to
workers vs impact to clients.
For 3) splitting the classpath up for each daemon wire compatibility is not
impacted, but we are potentially removing a bunch of APIs from the worker
and client classpath.  Most of these where shaded and users should not be
impacted by them being removed, but a few like servlet-api-2.5.jar are
likely to be removed.  So yes the impact here would likely be very small.
However on the client side if a topology wants to include LocalCluster
(like we do in a lot of examples) the topology jar will get a lot bigger.
LocalCluster needs access to nimbus, supervisor, and drpc server.  These
would not be on the worker classpath any more and would then need to be
packaged into the topology jar to make LocalCluster work.  In production I
would expect LocalCluster to be used by tests and not be included like we
do in a lot of examples.  This is more of a shift for how we expect users
to interact with the LocalCluster.
For 1) NodeInfo.port depending on how we do it, it could break wire
compatibility and API compatibility (which is what I would prefer).  We
could play some games to maintain compatibility, but for me it is enough of
a pain that I am not sure it is worth it.  However this is not likely to
impact workers because they don't use these APIs directly.  It might impact
clients but only if they have custom code to profile their topologies.  IF
they use the build in CLI/UI it would not be impacted.
For 2) nocamel would break API compatibility, but not wire compatibility.
This is not likely to impact workers because like with 1 workers don't
really interact with nimbus directly so it would not be a problem.  Old
clients running with older versions of storm would continue to work, but
any custom client code (think what gets run by storm jar) would need to be
recompiled/modified to be able to run on against a storm-2.x client.

- Bobby

Re: [DISCUSS] breaking changes in 2.x

[P. Taylor Goetz]

I agree with Kyle. I think trying to cling to being able to do rolling upgrades 
across major versions would be too limiting in terms of adding new features. If 
we can keep RU capability within major version lines, that seems like a fair 
tradeoff.

-Taylor

> On Nov 7, 2016, at 12:16 PM, Kyle Nusbaum  
> wrote:
> 
> I worry that making it a priority to have rolling upgrades between major 
> versions significantly restricts the kinds of changes that we can make, 
> including some kinds of changes that a major version increment is supposed to 
> mark. I'm not really in support of trying to do that.
> If we can't make changes that break compatibility now, when can we make them? 
> Can changes like that ever be made? I don't know that it's good to limit 
> ourselves like that.
> Trying to accommodate rolling upgrades is a good idea, but I'm not sure about 
> rejecting code changes across major versions to support them. 2.x represents 
> a large shift in the project, and I expect once the translation, etc. is 
> done, things will calm down and APIs will become more stable, allowing more 
> of our future releases to be rolling even across major versions. I'd rather 
> get these kinds of changes out of the way now in the 2.x release than cart 
> along the vestiges of 1.x from now on.
> What do others think about this?
> -- Kyle
> 
> On Monday, November 7, 2016, 3:10:08 AM CST, Bobby Evans 
>  wrote:Let's distinguish between wire 
> compatibility changes and API compatibility changes, along with impact to 
> workers vs impact to clients.
> For 3) splitting the classpath up for each daemon wire compatibility is not 
> impacted, but we are potentially removing a bunch of APIs from the worker and 
> client classpath.  Most of these where shaded and users should not be 
> impacted by them being removed, but a few like servlet-api-2.5.jar are likely 
> to be removed.  So yes the impact here would likely be very small.
> However on the client side if a topology wants to include LocalCluster (like 
> we do in a lot of examples) the topology jar will get a lot bigger.  
> LocalCluster needs access to nimbus, supervisor, and drpc server.  These 
> would not be on the worker classpath any more and would then need to be 
> packaged into the topology jar to make LocalCluster work.  In production I 
> would expect LocalCluster to be used by tests and not be included like we do 
> in a lot of examples.  This is more of a shift for how we expect users to 
> interact with the LocalCluster.
> For 1) NodeInfo.port depending on how we do it, it could break wire 
> compatibility and API compatibility (which is what I would prefer).  We could 
> play some games to maintain compatibility, but for me it is enough of a pain 
> that I am not sure it is worth it.  However this is not likely to impact 
> workers because they don't use these APIs directly.  It might impact clients 
> but only if they have custom code to profile their topologies.  IF they use 
> the build in CLI/UI it would not be impacted.
> For 2) nocamel would break API compatibility, but not wire compatibility. 
> This is not likely to impact workers because like with 1 workers don't really 
> interact with nimbus directly so it would not be a problem.  Old clients 
> running with older versions of storm would continue to work, but any custom 
> client code (think what gets run by storm jar) would need to be 
> recompiled/modified to be able to run on against a storm-2.x client.
> 
> - Bobby

Re: [DISCUSS] breaking changes in 2.x

[Kyle Nusbaum]

I worry that making it a priority to have rolling upgrades between major 
versions significantly restricts the kinds of changes that we can make, 
including some kinds of changes that a major version increment is supposed to 
mark. I'm not really in support of trying to do that.
If we can't make changes that break compatibility now, when can we make them? 
Can changes like that ever be made? I don't know that it's good to limit 
ourselves like that.
Trying to accommodate rolling upgrades is a good idea, but I'm not sure about 
rejecting code changes across major versions to support them. 2.x represents a 
large shift in the project, and I expect once the translation, etc. is done, 
things will calm down and APIs will become more stable, allowing more of our 
future releases to be rolling even across major versions. I'd rather get these 
kinds of changes out of the way now in the 2.x release than cart along the 
vestiges of 1.x from now on.
What do others think about this?
-- Kyle

On Monday, November 7, 2016, 3:10:08 AM CST, Bobby Evans 
 wrote:Let's distinguish between wire 
compatibility changes and API compatibility changes, along with impact to 
workers vs impact to clients.
For 3) splitting the classpath up for each daemon wire compatibility is not 
impacted, but we are potentially removing a bunch of APIs from the worker and 
client classpath.  Most of these where shaded and users should not be impacted 
by them being removed, but a few like servlet-api-2.5.jar are likely to be 
removed.  So yes the impact here would likely be very small.
However on the client side if a topology wants to include LocalCluster (like we 
do in a lot of examples) the topology jar will get a lot bigger.  LocalCluster 
needs access to nimbus, supervisor, and drpc server.  These would not be on the 
worker classpath any more and would then need to be packaged into the topology 
jar to make LocalCluster work.  In production I would expect LocalCluster to be 
used by tests and not be included like we do in a lot of examples.  This is 
more of a shift for how we expect users to interact with the LocalCluster.
For 1) NodeInfo.port depending on how we do it, it could break wire 
compatibility and API compatibility (which is what I would prefer).  We could 
play some games to maintain compatibility, but for me it is enough of a pain 
that I am not sure it is worth it.  However this is not likely to impact 
workers because they don't use these APIs directly.  It might impact clients 
but only if they have custom code to profile their topologies.  IF they use the 
build in CLI/UI it would not be impacted.
For 2) nocamel would break API compatibility, but not wire compatibility. This 
is not likely to impact workers because like with 1 workers don't really 
interact with nimbus directly so it would not be a problem.  Old clients 
running with older versions of storm would continue to work, but any custom 
client code (think what gets run by storm jar) would need to be 
recompiled/modified to be able to run on against a storm-2.x client.

- Bobby

Re: [DISCUSS] breaking changes in 2.x

[Bobby Evans]

Let's distinguish between wire compatibility changes and API compatibility 
changes, along with impact to workers vs impact to clients.
For 3) splitting the classpath up for each daemon wire compatibility is not 
impacted, but we are potentially removing a bunch of APIs from the worker and 
client classpath.  Most of these where shaded and users should not be impacted 
by them being removed, but a few like servlet-api-2.5.jar are likely to be 
removed.  So yes the impact here would likely be very small.
However on the client side if a topology wants to include LocalCluster (like we 
do in a lot of examples) the topology jar will get a lot bigger.  LocalCluster 
needs access to nimbus, supervisor, and drpc server.  These would not be on the 
worker classpath any more and would then need to be packaged into the topology 
jar to make LocalCluster work.  In production I would expect LocalCluster to be 
used by tests and not be included like we do in a lot of examples.  This is 
more of a shift for how we expect users to interact with the LocalCluster.
For 1) NodeInfo.port depending on how we do it, it could break wire 
compatibility and API compatibility (which is what I would prefer).  We could 
play some games to maintain compatibility, but for me it is enough of a pain 
that I am not sure it is worth it.  However this is not likely to impact 
workers because they don't use these APIs directly.  It might impact clients 
but only if they have custom code to profile their topologies.  IF they use the 
build in CLI/UI it would not be impacted.
For 2) nocamel would break API compatibility, but not wire compatibility. This 
is not likely to impact workers because like with 1 workers don't really 
interact with nimbus directly so it would not be a problem.  Old clients 
running with older versions of storm would continue to work, but any custom 
client code (think what gets run by storm jar) would need to be 
recompiled/modified to be able to run on against a storm-2.x client.

- Bobby

Re: [DISCUSS] breaking changes in 2.x

[P. Taylor Goetz]

Can you provide a hypothetical example for how #3 might break something for 
users?

It seems like most of the cases of backward incompatibility are not 
typical/average use cases, and that rolling upgrades would only be affected in 
certain edge cases. If that’s the case then I’m fine with the proposed changes.

-Taylor


> On Nov 7, 2016, at 10:43 AM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
> 
> Made a mistake and put something on private that never should have been 
> there.  Here is the discussion in full so far.
> In response to Jungtake removing the nocamel option will change 
> set_bar/get_bar in the generated thrift code to setBar/getBar.  So any thrift 
> object that clients interact with will need to make similar changes.
> - Bobby  
> 
> - Forwarded Message -From: Bobby Evans <ev...@yahoo-inc.com>To: 
> "priv...@storm.apache.org" <priv...@storm.apache.org>Sent: Monday, November 
> 7, 2016, 3:37:50 AM CST Subject: Re: [DISCUSS] breaking changes in 2.x 
> Sorry you are right, I put in the wrong mailing list.  I feel dumb.  Will 
> move it to dev.
> - Bobby
> 
> On Sunday, November 6, 2016, 2:18:33 AM CST, P. Taylor Goetz 
> <ptgo...@gmail.com> wrote:Can we move this discussion to dev@? There doesn't 
> seem to be anything sensitive about the subject.
> -Taylor
> On Nov 6, 2016, at 1:28 AM, Jungtaek Lim <kabh...@gmail.com> wrote:
> 
> 
> Regarding breaking change, I'm OK to break backward UX compatibility if we're 
> sure that it gives better UX. And since we're talking about next major, if we 
> don't do it now, we might have no chance to do the near future.
> For 1) this should be corrected, and for 2) I'm not sure how it affects to 
> end-users, but it would be better to address if it doesn't hurt user codes 
> much. 3) I think expected user impact is similar to what we did it for adding 
> dependencies to shade list. Then it doesn't look matter to me.
> Thanks,Jungtaek Lim (HeartSaVioR)
> 2016년 11월 5일 (토) 오후 11:01, Bobby Evans <bo...@apache.org>님이 작성:
> 
> I have been working on getting some of clojure code translated to java, and I 
> have run into a few issues that I really would like to address, but will 
> impact users.  Because 2.x has not been released yet technically these should 
> be OK, but I want to get feedback from others before I spend a lot of time on 
> them or even file a JIRA.
> 1)WHAT: The thrift NodeInfo.port should be a single long, not a set of 
> longs.USER IMPACT: it is exposed to end users through the profiling request 
> API. BACK COMPAT: it is possible, but I would prefer not to.
> 
> 2)WHAT: Using 'nocamel' when generating thrift makes generated exceptions 
> less useful and the API less java like.USER IMPACT: users when upgrading 
> would need to modify some API calls when setting/reading thrift objects.BACK 
> COMPAT: most older clients should still work for a lot of things
> 3) WHAT: split up storm-core so we have class path separation between daemons 
> and a true client.USER IMPACT: Users may need to include new dependencies to 
> get what they want.  Old topologies may not get access to everything that 
> they want.BACK COMPAT:  we could leave some old dependencies in place that 
> are not needed, but why?
> If we do all of these it is likely that profiling requests from an old client 
> will not work, but for the most part a 1.x client would still work with 2.x.
> - Bobby
> 

Re: Fw: Re: [DISCUSS] breaking changes in 2.x

[Bobby Evans]

For all of these we should be able to support a rolling upgrade from 1.x with 
some caveats.
1) There are a few possibilities on how to make this happen, but none of them 
are ideal.  If you feel strongly about a rolling upgrade I might skip this.
2) would work for all workers that do not access objects from storm.thrift 
directly.  (which I think should be most topologies)

3) Would require us to do changes similar to what we did when we first shaded 
everything.  Have users compile their topologies against the newer version of 
storm, but override some dependencies to match the older version of storm.  
Then when it is deployed it could run on either version of storm.
- Bobby

On Monday, November 7, 2016, 3:56:08 AM CST, Harsha Chintalapani 
<st...@harsha.io> wrote:My only concern here is the rolling upgrade of storm 
cluster. We supported
the rolling upgrade going to 0.10 and broke it because of storm 1.x
release. Users are not inclined to upgrade to a new release if it's not
rolling upgradable. In this case, it looks like we are going to break this.
Correct me if I am wrong here.

Thanks,
Harsha

On Mon, Nov 7, 2016 at 7:43 AM Bobby Evans <ev...@yahoo-inc.com.invalid>
wrote:

> Made a mistake and put something on private that never should have been
> there.  Here is the discussion in full so far.
> In response to Jungtake removing the nocamel option will change
> set_bar/get_bar in the generated thrift code to setBar/getBar.  So any
> thrift object that clients interact with will need to make similar changes.
> - Bobby
>
>  - Forwarded Message -From: Bobby Evans <ev...@yahoo-inc.com>To: "
> priv...@storm.apache.org" <priv...@storm.apache.org>Sent: Monday,
> November 7, 2016, 3:37:50 AM CST Subject: Re: [DISCUSS] breaking changes in
> 2.x
>  Sorry you are right, I put in the wrong mailing list.  I feel dumb.  Will
> move it to dev.
> - Bobby
>
> On Sunday, November 6, 2016, 2:18:33 AM CST, P. Taylor Goetz <
> ptgo...@gmail.com> wrote:Can we move this discussion to dev@? There
> doesn't seem to be anything sensitive about the subject.
> -Taylor
> On Nov 6, 2016, at 1:28 AM, Jungtaek Lim <kabh...@gmail.com> wrote:
>
>
> Regarding breaking change, I'm OK to break backward UX compatibility if
> we're sure that it gives better UX. And since we're talking about next
> major, if we don't do it now, we might have no chance to do the near future.
> For 1) this should be corrected, and for 2) I'm not sure how it affects to
> end-users, but it would be better to address if it doesn't hurt user codes
> much. 3) I think expected user impact is similar to what we did it for
> adding dependencies to shade list. Then it doesn't look matter to me.
> Thanks,Jungtaek Lim (HeartSaVioR)
> 2016년 11월 5일 (토) 오후 11:01, Bobby Evans <bo...@apache.org>님이 작성:
>
> I have been working on getting some of clojure code translated to java,
> and I have run into a few issues that I really would like to address, but
> will impact users.  Because 2.x has not been released yet technically these
> should be OK, but I want to get feedback from others before I spend a lot
> of time on them or even file a JIRA.
> 1)WHAT: The thrift NodeInfo.port should be a single long, not a set of
> longs.USER IMPACT: it is exposed to end users through the profiling request
> API. BACK COMPAT: it is possible, but I would prefer not to.
>
> 2)WHAT: Using 'nocamel' when generating thrift makes generated exceptions
> less useful and the API less java like.USER IMPACT: users when upgrading
> would need to modify some API calls when setting/reading thrift
> objects.BACK COMPAT: most older clients should still work for a lot of
> things
> 3) WHAT: split up storm-core so we have class path separation between
> daemons and a true client.USER IMPACT: Users may need to include new
> dependencies to get what they want.  Old topologies may not get access to
> everything that they want.BACK COMPAT:  we could leave some old
> dependencies in place that are not needed, but why?
> If we do all of these it is likely that profiling requests from an old
> client will not work, but for the most part a 1.x client would still work
> with 2.x.
> - Bobby
>
>

Re: Fw: Re: [DISCUSS] breaking changes in 2.x

[Harsha Chintalapani]

My only concern here is the rolling upgrade of storm cluster. We supported
the rolling upgrade going to 0.10 and broke it because of storm 1.x
release. Users are not inclined to upgrade to a new release if it's not
rolling upgradable. In this case, it looks like we are going to break this.
Correct me if I am wrong here.

Thanks,
Harsha

On Mon, Nov 7, 2016 at 7:43 AM Bobby Evans <ev...@yahoo-inc.com.invalid>
wrote:

> Made a mistake and put something on private that never should have been
> there.  Here is the discussion in full so far.
> In response to Jungtake removing the nocamel option will change
> set_bar/get_bar in the generated thrift code to setBar/getBar.  So any
> thrift object that clients interact with will need to make similar changes.
> - Bobby
>
>  - Forwarded Message -From: Bobby Evans <ev...@yahoo-inc.com>To: "
> priv...@storm.apache.org" <priv...@storm.apache.org>Sent: Monday,
> November 7, 2016, 3:37:50 AM CST Subject: Re: [DISCUSS] breaking changes in
> 2.x
>  Sorry you are right, I put in the wrong mailing list.  I feel dumb.  Will
> move it to dev.
> - Bobby
>
> On Sunday, November 6, 2016, 2:18:33 AM CST, P. Taylor Goetz <
> ptgo...@gmail.com> wrote:Can we move this discussion to dev@? There
> doesn't seem to be anything sensitive about the subject.
> -Taylor
> On Nov 6, 2016, at 1:28 AM, Jungtaek Lim <kabh...@gmail.com> wrote:
>
>
> Regarding breaking change, I'm OK to break backward UX compatibility if
> we're sure that it gives better UX. And since we're talking about next
> major, if we don't do it now, we might have no chance to do the near future.
> For 1) this should be corrected, and for 2) I'm not sure how it affects to
> end-users, but it would be better to address if it doesn't hurt user codes
> much. 3) I think expected user impact is similar to what we did it for
> adding dependencies to shade list. Then it doesn't look matter to me.
> Thanks,Jungtaek Lim (HeartSaVioR)
> 2016년 11월 5일 (토) 오후 11:01, Bobby Evans <bo...@apache.org>님이 작성:
>
> I have been working on getting some of clojure code translated to java,
> and I have run into a few issues that I really would like to address, but
> will impact users.  Because 2.x has not been released yet technically these
> should be OK, but I want to get feedback from others before I spend a lot
> of time on them or even file a JIRA.
> 1)WHAT: The thrift NodeInfo.port should be a single long, not a set of
> longs.USER IMPACT: it is exposed to end users through the profiling request
> API. BACK COMPAT: it is possible, but I would prefer not to.
>
> 2)WHAT: Using 'nocamel' when generating thrift makes generated exceptions
> less useful and the API less java like.USER IMPACT: users when upgrading
> would need to modify some API calls when setting/reading thrift
> objects.BACK COMPAT: most older clients should still work for a lot of
> things
> 3) WHAT: split up storm-core so we have class path separation between
> daemons and a true client.USER IMPACT: Users may need to include new
> dependencies to get what they want.  Old topologies may not get access to
> everything that they want.BACK COMPAT:  we could leave some old
> dependencies in place that are not needed, but why?
> If we do all of these it is likely that profiling requests from an old
> client will not work, but for the most part a 1.x client would still work
> with 2.x.
> - Bobby
>
>

Fw: Re: [DISCUSS] breaking changes in 2.x

[Bobby Evans]

Made a mistake and put something on private that never should have been there.  
Here is the discussion in full so far.
In response to Jungtake removing the nocamel option will change set_bar/get_bar 
in the generated thrift code to setBar/getBar.  So any thrift object that 
clients interact with will need to make similar changes.
- Bobby  
 
 - Forwarded Message -From: Bobby Evans <ev...@yahoo-inc.com>To: 
"priv...@storm.apache.org" <priv...@storm.apache.org>Sent: Monday, November 7, 
2016, 3:37:50 AM CST Subject: Re: [DISCUSS] breaking changes in 2.x 
 Sorry you are right, I put in the wrong mailing list.  I feel dumb.  Will move 
it to dev.
- Bobby

On Sunday, November 6, 2016, 2:18:33 AM CST, P. Taylor Goetz 
<ptgo...@gmail.com> wrote:Can we move this discussion to dev@? There doesn't 
seem to be anything sensitive about the subject.
-Taylor
On Nov 6, 2016, at 1:28 AM, Jungtaek Lim <kabh...@gmail.com> wrote:


Regarding breaking change, I'm OK to break backward UX compatibility if we're 
sure that it gives better UX. And since we're talking about next major, if we 
don't do it now, we might have no chance to do the near future.
For 1) this should be corrected, and for 2) I'm not sure how it affects to 
end-users, but it would be better to address if it doesn't hurt user codes 
much. 3) I think expected user impact is similar to what we did it for adding 
dependencies to shade list. Then it doesn't look matter to me.
Thanks,Jungtaek Lim (HeartSaVioR)
2016년 11월 5일 (토) 오후 11:01, Bobby Evans <bo...@apache.org>님이 작성:

I have been working on getting some of clojure code translated to java, and I 
have run into a few issues that I really would like to address, but will impact 
users.  Because 2.x has not been released yet technically these should be OK, 
but I want to get feedback from others before I spend a lot of time on them or 
even file a JIRA.
1)WHAT: The thrift NodeInfo.port should be a single long, not a set of 
longs.USER IMPACT: it is exposed to end users through the profiling request 
API. BACK COMPAT: it is possible, but I would prefer not to.

2)WHAT: Using 'nocamel' when generating thrift makes generated exceptions less 
useful and the API less java like.USER IMPACT: users when upgrading would need 
to modify some API calls when setting/reading thrift objects.BACK COMPAT: most 
older clients should still work for a lot of things
3) WHAT: split up storm-core so we have class path separation between daemons 
and a true client.USER IMPACT: Users may need to include new dependencies to 
get what they want.  Old topologies may not get access to everything that they 
want.BACK COMPAT:  we could leave some old dependencies in place that are not 
needed, but why?
If we do all of these it is likely that profiling requests from an old client 
will not work, but for the most part a 1.x client would still work with 2.x.
- Bobby