Unlock opensaml-parent ?

[Ian Young]

> On 23 Oct 2015, at 18:25, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> 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.

When we're testing that new version of the IdP, we're testing it against the old version of OpenSAML but with the new dependencies introduced by the later parent POM. Isn't that enough?

If it's not, you're saying that *recompiling* OpenSAML against dependencies with an API which it isn't incompatible with at runtime might change its behaviour. Is that really the thing we're worried about here?

My take would be that you're going to get *the same code* out of the recompilation, and the rebuild is always going to result in an essentially unchanged OpenSAML artifact with a new version number.

(In fact, of course, we'll almost always be talking about something further up the stack, like java-support, because OpenSAML tends to get involved in releases just as much as the IdP proper -- but the same argument would apply)

    -- Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3563 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/dev/attachments/20151023/6cb1da88/attachment.p7s>