chore: Add decision record concerning downward compatibiity #1797
Conversation
Signed-off-by: Lars Geyer-Blaumeiser <[email protected]>
|
|
@rafaelmag110 @ndr-brt : THis is still a draft, but I would appreciate, if you could look into the decision and rationale and basically give feedback. It will make it ready for review when I filled all relevant data models going through the management api and identifying the relevant assets. |
|
|
||
| ## Decision | ||
|
|
||
| DSP assets, like the catalog, which are forwarded directly to a caller through the management api, have to be kept downward compatible as long as the DSP version through which the asset is retrieved is supported. There is no compatibility requirement between two different DSP versions concerning such assets. |
There was a problem hiding this comment.
"have to be kept downward compatible as long as the DSP version through which the asset is retrieved is supported"
Can this statement be explained in different terms?
There was a problem hiding this comment.
I left a comment inline, but I'd like to provide my perspective on why that statement could be explained in different terms.
What we should try to achieve here is a decision on how we handle protocol versions, as in, how many DSP versions a certain tractusx-edc version should support and how we guarantee no changes are introduced to a currently supported version.
In my perspective there is no point in guaranteeing two distinct DSP versions are downwards compatible. To achieve this you would need to keep deprecated properties in newer versions, which you shouldn't need in the first place because you also support the previous (deprecated) version. In this sense, keeping up with deprecation is more simple because adopters can look for and remove deprecated DSP versions and not deprecated properties in recent versions.
Also, the requirement from CatenaX is that communication between two participants is not broken due to stack upgrades. If two participants communicate over a specific version of the DSP protocol, one of those participants can only upgrade its stack to a latter connector version IF this new version also supports the previous protocol version. I believe this is possible with the multi protocol support from the Connector. TractusX responsibility then is to define which DSP protocol versions have to be supported for each TractusX release.
In terms of testing, in my perspective tractusx-edc should only guarantee that the protocol data model never changes for an already supported version. This is not really testing for downward compatibility, but for consistency.
|
Nevertheless, many thanks @lgblaumeiser for pushing this decision record. |
WHAT
Decision Record on Downward Compatibility
WHY
As we had currently downward compatibility issues which lead to applications to fail to continue to work, a decision needs to be done about the expectation of the provided service implementation.