The ORM feature is about translating a request for a Service which is considered legacy/deprecated and return instead the new one; this obviously requires that ORM maintains such "shadow" services as super-interfaces of the new one
I get that
so we need to pay attention on breaking changes to make the "shadowing" happen.
That I don't get. What are you saying here. Looking at the suggested pull request you are proposing to not allow the ORM service shadowing. This would force us to update to newer services earlier. Basically each time we upgrade ORM and there would be a service change we would need to change as well. With this setting enabled it could be that we rely on a legacy service which due to shadowing still works. So is our intend to always use the latest services and avoid shadowing when possible?
To eagerly catch usage of "legacy" shadow services we also introduced an environment option to disable the ORM compatibility feature, so that we can fail fast in our testsuite.
Fair enough
This issue is all about making sure that we regularly run the testuiste with that option set.
well, what do you mean with regularly here. Clearly what you are suggesting in your comments on in the pull request as a matter of fact is to run it all the times. Again, fair enough. I am just not sure about the way this is setup. Why do we use a system property for this, instead of relying on the test base/setup classes?
|