Yes, so what I would propose is...
If we add in a new dependency to the storm lib directory that is not shaded, or
decide to stop shading a dependency it should at least be a minor version bump,
but I would prefer a major version bump (potentially binary incompatible
change).If we bump a version number for an unshaded dependency it should follow
with a corresponding version bump in storm. Major for Major, minor for minor,
bugfix for bugfix (which can more or less be ignored). Except in the cases
like guava where they more or less ignore this process and any change can break
backwards compatibility so just be careful.If we decide to remove a dependency
or start shading a dependency that was not shaded previously, it should be like
adding a new one, I would prefer a major version bump, but minor is
acceptable.
my 2 cents.
- Bobby
On Thursday, May 19, 2016 3:39 PM, P. Taylor Goetz <ptgo...@gmail.com>
wrote:
But if we shade a dependency, are’t we effectively making it *private*, in
which case a minor revision bump would be unnecessary? I would think using the
shaded/private versions of storm’s dependencies should be done at one’s own
risk, i.e. knowing they are subject to change.
-Taylor
> On May 19, 2016, at 2:41 PM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
>
> 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
>>
>
