Another 3rd-party version policy question

[Cantor, Scott]

On 11/2/15, 4:26 PM, "dev on behalf of Tom Zeller" <dev-bounces at shibboleth.net on behalf of tzeller at dragonacea.biz> wrote:



>I guess I’m wondering why the version policy considers “any” 3rd-party library to be part of the public API and if that’s worth reconsidering.

The only alternative would be for us to explicitly identify which libraries were off limits, and then also ensure we had no APIs exposing anything from them.

>While updating spymemcache and hibernate-entitymanager, I wondered if 3rd-party dependencies of impl projects should be versioned the same as dependencies of api projects. While versioning strictly very much seems like the right thing to do, I also wonder if that would technically result in a major version bump because we want to take advantage of a new feature of a 3rd-party impl dependency which also happens to not follow our version policy (i.e. both adds and removes a method). I guess we could just note such a deviation from the policy in our release notes, but the general question is interesting to me.

It's not impossible, if the dependency is truly internal only. It's not just a function of which module of ours is using something, but how it's using it. But clearly that's easier to wall off if it's an implementation class on our side, and I guess if it's only a transitive dependency via an impl module, that wouldn't be visible to correct maven file for a plugin.

-- Scott

>