Unlock opensaml-parent ?

[Cantor, Scott]

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

>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?

I rarely commit to any public statements involving the adequacy of my testing.

The IdP unit and integration tests would be running with the new, but the OpenSAML tests would be running with the old one. Our real world smoke tests would have the mix, but they're only so thorough.

>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?

No, my assumption is that the unit tests might catch something, but they don't have a chance to try because the OpenSAML tests are running in a build that's done with the old dependency. It's not the recompilation, just the fact that the tests run at that point.

>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.

Yes, our code's not changing in either case.

It's a question of test coverage, clearly. But again, I don't have any illusions about that. Something will break at some point. We just may choose to live with that risk, given that it is relatively small. Which is the answer to Tom's versioning question. We've bumped libraries in minor updates because the assumption is they aren't usually pulling or changing APIs as a rule. That doesn't mean the chance is zero though.

The advantage, if there is one, of unlocking the POM uniformly and always doing at least a patch release of all our code, is that we try and catch *our* use of APIs that turn out to have changed or gone missing.

I'm just saying that *is* a benefit to that consistency. Maybe not enough of one, but it's not zero.

-- Scott