We almost never add new dependencies to storm-core without shading first. I
don't think it will be an explosion in minor revisions, but that is just me.
- Bobby
On Wednesday, May 18, 2016 4:58 PM, P. Taylor Goetz <ptgo...@gmail.com>
wrote:
Good point.
I guess the problem is that we have no way of knowing what dependencies a user
could potentially use in their topologies. Semantic versioning can't really
help with that without a potential explosions of minor revisions. Maybe the
best option is to document such dependency changes in release notes?
-Taylor
> On May 18, 2016, at 4:47 PM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
>
> But adding something that was not there before is just the same thing. If I
> have a topology that is using guava, and storm adds in a dependency with a
> different version to the classpath without shading it, I just broke that
> topology.
> - Bobby
>
> On Wednesday, May 18, 2016 2:26 PM, P. Taylor Goetz <ptgo...@gmail.com>
>wrote:
>
>
>
>
> On May 18, 2016, at 2:46 PM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
> If this is for 1.x then we might want to go to 1.1, not sure what the policy
> is for adding something new to the classpath.
> - Bobby
>
> There was a discussion thread around this. My feeling is that for 1.x, since
> we are adding APIs we should bump the minor version (i.e. 1.1.x).
> I don’t think adding something to the classpath warrants a minor version bump
> unless it adds something to a *Storm* API.
> -Taylor
>
