Unlock opensaml-parent ?

[Cantor, Scott]

On 10/23/15, 1:16 PM, "dev on behalf of Ian Young" <dev-bounces at shibboleth.net on behalf of ian at iay.org.uk> wrote:

>In this particular case, I think we're seeing something suggested just because it is more consistent without a clear idea of where the benefit will come from that will pay for all the extra work that will be involved. It seems to throw the whole idea of versioning the components independently out of the window.

Well, that sort of independence has been, to some degree, a fiction, but I guess the point here might be illustrated by an example:

We do a minor IdP update and decide we need to update a dependency that is shared with OpenSAML. So we have to unlock the IdP parent. If we don't change OpenSAML, and presumably just decide to keep shipping the same version in the IdP, we wouldn't have to unlock and rebuild it. But now the OpenSAML build is against a different version of the dependency.

That can break, if the dependency made a change we overlook, but (let's assume decent test coverage) wouldn't if we unlock and bump OpenSAML.

> I can't see how we can believe that this is broken to the extent that would justify this without also giving up on semantic versioning for our own artifacts: for example, there's no requirement for people plugging things into the IdP to be using exactly the same parent POM as we did in a particular release. It's supposed to be the APIs that matter, not the way the artifact was built.

It's the APIs I'm thinking of. The dependencies are part of the API.

This is just the same thread as the other one about dependency versions. That's what it's always about to me.

The *build* hasn't materially changed, ever, that I can see. Just the Java compiler version and that's locked.

-- Scott