Skip to Content
Last modified by Helena on 2025/09/10 11:19
From version 2.1
edited by Helena
on 2025/05/15 15:48
Change comment: Created by office importer.
To version 2.3
edited by Helena
on 2025/05/16 10:54
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,0 +1,1 @@
1 +14 ANNEX Semantic Versioning
Content
... ... @@ -1,4 +1,6 @@
1 -= 14 ANNEX Semantic Versioning =
1 +{{box title="**Contents**"}}
2 +{{toc/}}
3 +{{/box}}
2 2  
3 3  == 14.1 Introduction to Semantic Versioning ==
4 4  
... ... @@ -6,9 +6,9 @@
6 6  
7 7  In systems with many dependencies, releasing new artefact versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade an artefact without having to release new versions of every dependent artefact). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your data modelling forward.
8 8  
9 -As a very successful solution to the similar problem in software development, "Semantic Versioning" [[__semver.org__>>url:http://semver.org/]][[ >>url:http://semver.org/]]proposes a simple set of rules and requirements that dictate how version numbers are assigned and incremented. These rules make also perfect sense in the world of versioned data modelling and help to solve the "dependency hell" encountered with previous versions of SDMX. SDMX 3.0 applies thus the Semantic Versioning rules on all versioned SDMX artefacts. Once you release a versioned SDMX artefact, you communicate changes to it with specific increments to your version number.
11 +As a very successful solution to the similar problem in software development, "Semantic Versioning" [[__semver.org__>>https://semver.org/]] proposes a simple set of rules and requirements that dictate how version numbers are assigned and incremented. These rules make also perfect sense in the world of versioned data modelling and help to solve the "dependency hell" encountered with previous versions of SDMX. SDMX 3.0 applies thus the Semantic Versioning rules on all versioned SDMX artefacts. Once you release a versioned SDMX artefact, you communicate changes to it with specific increments to your version number.
10 10  
11 -**This SDMX 3.0(.0) specification inherits the original **[[__**semver.org**__>>url:https://semver.org/]]**[[ >>url:https://semver.org/]]2.0.0 wording (license: __[[Creative Commons >>url:http://creativecommons.org/licenses/by/3.0/]][[- >>url:http://creativecommons.org/licenses/by/3.0/]][[CC BY 3.0>>url:http://creativecommons.org/licenses/by/3.0/]]__[[)>>url:http://creativecommons.org/licenses/by/3.0/]] and applies it to versioned SDMX structural artefacts.** Under this scheme, version numbers and the way they change convey meaning about the underlying data structures and what has been modified from one version to the next.
13 +**This SDMX 3.0(.0) specification inherits the original **[[__**semver.org**__>>https://xwiki:semver.org]]** 2.0.0 wording (license: [[__Creative Commons - CC BY 3.0__>>https://creativecommons.org/licenses/by/3.0/]]) and applies it to versioned SDMX structural artefacts.** Under this scheme, version numbers and the way they change convey meaning about the underlying data structures and what has been modified from one version to the next.
12 12  
13 13  == 14.2 Semantic Versioning Specification for SDMX 3.0(.0) ==
14 14