Update lm-commons/lmc-rbac and signature for HasVerifiedEmailAssertion::assert

[stweil]

The signature was changed in the interface starting with lm-commons/lmc-rbac 2.2.0, see related commit.

[demiankatz]

Thanks, @stweil. That's a somewhat surprising change to make in a minor release of a library, though I suppose it's not a backward break since the upstream code is making the type more general, so downstream code with more specific types should remain compatible. And that raises the question: should we leave the type alone in HasVerifiedEmailAssertion, since in the instance of VuFind, it should still be true? Or did you encounter a problem that required this change to be made?

[stweil]

I got a runtime exception (directly when loading VuFind's start page in a web browser) because of the signature mismatch after updating my local packages with composer upgrade.

This exception either requires limiting the version in composer.json or updating the signature. We could use a signature without a type for $identity which would work with old and new releases of lm-commons/lmc-rbac. Or we go forward, require the newer release of lm-commons/lmc-rbac and fix the signature.

As the VuFind code directly uses lm-commons/lmc-rbac, it should be mentioned in composer.json anyway.

[demiankatz]

Thanks, @stweil! Maybe the best solution would be to open a PR against release-11.0 that locks the library to the current working version. That way, we can ensure that users of 11.0.1 don't run into this problem. And this PR can remain open for inclusion in 11.1 or 12.0 to bring us up to compatibility with the newer version.

I don't think the lmc-rbac changelog should claim that release 2.2.0 has no backward compatibility breaks, though, since it clearly does!

[stweil]

... and I agree that a minor version should not contain a change like this one. But I am afraid that we have to accept it as it is.

[stweil]

Maybe the best solution would be to open a PR against release-11.0 that locks the library to the current working version. That way, we can ensure that users of 11.0.1 don't run into this problem.

Done, see PR #4909.

[demiankatz]

Thanks, @stweil, I'll move this to the 12.0 milestone so we don't introduce our own breaking change until the next major version.