-
Notifications
You must be signed in to change notification settings - Fork 6
Expected support of older versions
If two actors exchange data with SDScom, the versions they use should ideally be the same. In real life, this will not always be possible. If the exporting system uses a newer version than the importing system, but the first two parts of the version numbers match (e.g. 4.2.3 -> 4.2.0), this should cause no major issues. The other way (4.2.0 -> 4.2.3), the import will lack any data fields added between the two versions.
If the versions differ in the second version number part (see the version number page for explanations), there will be more deviations and less data successfully exchanged. To limit such issues, implementors are generally expected to follow these simple rules:
- You should update your implementation to the latest version of SDScom at least every two years.
- Deploy all versions that you have implemented at least for a period of two years. During this period, usually four versions will have been published.
Some releases (starting with version 4.4.0) are marked as "LTS" or long-term support version. They will be maintained for an enhanced period of time to cover legal changes. While scope enhancements would go into higher version numbers (4.4.1 or 5.0.0), any new or modified legal requirements within the scope of SDScom's implementation at release time, but introduced thereafter, would go into a release 4.4.0.1. This ensures that changes are reduced to a minumum so that you can keep your systems up to date with low implementation costs.
Long-term support versions are considered to be stable and robust regarding their scope and data representation, and are maintained for at least three years after release. As a minimum, there must be one newer LTS version before maintenance can stop. Until when an LTS version is supported is written on the release page. This may be prolonged by a decision of the SDSCom Steering Committee, but will never be shortened.
SDScom gives you two options to keep your systems up to date:
-
Continuous upgrading: The more versions you have adopted in your software, the better for data exchange: It will offer the user a better choice of versions to match the export/import partner requirements. Adopting every version will not increase the implementation burden too much because all changes from any version n to n+1 will also be part of n+x and thus your next update. You should expect one to two version per year-
-
LTS versions: Alternatively (and especially if you need to define your budget well in advance), you can choose to implement long-term support versions only. There will be no changes that are not related to legal requirements, so if you need those changes, you will need to touch your system anyway to modify user input, processing and data storage. SDScom update costs will hide easily in this bundle.
Supporting older versions usually means no trouble at all, except for deploying the older export/import configuration that already exists. Your software might develop further and thus the connection between data fields in your system and in the XML file might break. But in a thoughtful implementation this just means that a data field will be empty, not that the export/import is impossible. The SDScom group does not expect you to fix all such issues for older SDScom versions, but suggest you coordinate such internal data format changes with SDScom updates to the latest version, and advise your customer that he should upgrade the SDScom version if a data lack with older version happens.
It is important to maintain a common upgrade policy that is practical for all industry participants. If the above does not match your needs or ideas, please contact eSDScom Alliance, e.g. via email info@esdscom.eu. We strive to support you properly for the best possible data exchange.