Applications and Devices based on different versions of
Applications and Devices based on different versions of the information model Application 1. 0 Application 1. 1 Application 1. 2 For „backward incompatible“ versions: - Formerly deprecated artifacts deleted - New artifacts added For „backward compatible“ versions: - New artifacts added - Old artifacts not deleted, but marked as deprecated Device 1. 0 Device 1. 1 Application 2. 0 Device 1. 2 Device 2. 0
Application keeps being constant Devices get updated (or new devices added)
Application keeps being constant Devices get updated (or new devices added) Application 1. 0 For „backward compatible“ versions on device: Old application manages all devices with the functions provided by 1. 0 version For „backward incompatible“ versions on device: Functions provided by old application fall behind 1. 0 version Device 1. 0 Device 1. 1 Device 1. 2 Device 2. 0
Applications get updated (or new applications added) Device keeps being constant
Applications get updated (or new applications added) Device keeps being constant Application 1. 0 Application 1. 1 Application 1. 2 Application 2. 0 For „backward incompatible“ versions: Even if relevant artifacts would be known, functions provided by new application fall behind 1. 0 version Device 1. 0 For „backward compatible“ versions: Application still holds artifacts of 1. 0 version, but needs to know, which ones are the ones to be used Conclusion ! Artifacts have to be marked with the first supported release they were in
How to overcome barrier to „backward incompatible“ versions Applications constant / Device updated (or new device)
How to overcome barrier to „backward incompatible“ versions Applications constant / Device updated (or new device) Application 1. 0 Application 1. 1 Application 1. 2 If all unsupported artifacts have been marked deprecated before (and replacing artifacts have been defined), new device can be managed with former feature set If artifacts are unexpectedly not supported and no replacing artifacts are defined => function gets lost Device 2. 0
How to overcome barrier to „backward incompatible“ versions Application updated (or new application) / Devices constant
How to overcome barrier to „backward incompatible“ versions Application updated (or new application) / Devices constant Application 2. 0 If all deleted artifacts have been marked deprecated before (and replacing artifacts have been defined), old device can be managed with former feature set If artifacts get deleted and replacing artifacts are not supported in older models, function gets lost Device 1. 0 Device 1. 1 Device 1. 2
Conclusion ! If all changes from version n to n+1 follow the rules for backward compatibility, respectively only artifacts, which got marked deprecated during former updates already, get removed from the model, then backward compatibility is not an absolute, but a relative characteristic! Example: Version n+1 will be backward compatibility to version n, but probably not to version n-2 This would be a great improvement, because current way of thinking requires operators to - update all devices and applications to the latest backward compatible version - before updating the first application or device to a backward incompatible version In the proposed “sliding window approach”, number of releases and time period of backward compatibility are a compromise between - programming effort for continued support of deprecated artifacts - operational effort for roll-out of releases
16. 12 19. 2>16. 12 19. 10>>16. 12 20. 2>>19. 2 21. 3>>19. 10 First idea/proposal for a new numbering scheme: Numbering could base on release dates (e. g. yy. MM). Version number could start with the latest supported release and end with the oldest release, which is still entirely covered by (partly deprecated) artifacts. Some symbol could express number of releases in between. The planned TR-532 v 1. 1 could be named instead TR-532 v 19. 2>16. 12 Numbering of pre-release versions could still follow § 9 of semver. org Version numbering of implementations could still follow § 10 of semver. org Aforementioned backward compatibility is in principle a linear stream, but branches could also be expressed. Example: TR-599 v 20. 5>TR-532 v 19. 2 could be a branch, which origins from TR-532 v 1. 1, but contains functions that are not included in any later versions of TR-532.
- Slides: 11
