+1 I agree. I think we have been considering that the clojure migration/JStorm merge would become 2.0. Maybe we should reconsider that in order to allow major version bumps and closer adherence to semantic versioning. I can also think of a few areas where I’d like to see some backward-incompatible version changes.
-Taylor > On May 20, 2016, at 10:25 AM, Bobby Evans <[email protected]> wrote: > > 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>> wrote: >>> >>> >>> >>> >>> On May 18, 2016, at 2:46 PM, Bobby Evans <[email protected]> >>> 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
