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
