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 >> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
