Changes for page Guidelines on the Versioning of SDMX Artefacts

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -22,9 +22,10 @@
22	22
23	23	The proposed versioning system is based on the Semantic Versioning 2.0 specification{{footnote}}http://www.semver.org{{/footnote}}, namely:
24	24
25		-==== MAJOR.MINOR.PATCH{{footnote}}It should be noted that the SDMX standard specifies no limitation as to the number of components in the versioning system. The option proposed here is thus nothing but a recommended convention.{{/footnote}} ====
	25	+(% class="wikigeneratedid" id="HMAJOR.MINOR.PATCH" %)
	26	+MAJOR.MINOR.PATCH{{footnote}}It should be noted that the SDMX standard specifies no limitation as to the number of components in the versioning system. The option proposed here is thus nothing but a recommended convention.{{/footnote}}
26	26
27		-However, as the "patch" component will generally not be used extensively in SDMX, it is proposed to limit the coding to MAJOR.MINOR as long as no patches are implemented. Concretely, this means that version number 2.1.0 will be abridged to 2.1 as long as no patch is implemented. When a patch is implemented, the version number then becomes 2.1.1. At subsequent MAJOR change in the versioning the PATCH component will disappear (2.4.7 3.0).
	28	+However, as the "patch" component will generally not be used extensively in SDMX, it is proposed to limit the coding to MAJOR.MINOR as long as no patches are implemented. Concretely, this means that version number 2.1.0 will be abridged to 2.1 as long as no patch is implemented. When a patch is implemented, the version number then becomes 2.1.1. At subsequent MAJOR change in the versioning the PATCH component will disappear (2.4.7 → 3.0).
28	28
29	29	The most severe change has always precedence over other types of changes. For example, if the MAJOR and MINOR parts of the version number are impacted by changes, only the MAJOR component will be impacted. This means that version 3.2.1 will become 4.0.
30	30
...	...	@@ -34,7 +34,7 @@
34	34
35	35	The criterion for deciding which component is impacted is the severity of the change, i.e. the possibility of maintaining backward and forward compatibility between the different versions of an artefact.
36	36
37		-==== a. Description of backward/forward compatibility ====
	38	+== a. Description of backward/forward compatibility ==
38	38
39	39	Backward compatibility is defined as: An item (e.g. a data message) that was produced and validated with the previous version of an artefact (e.g. a DSD) can still be successfully validated using the newest version of the same artefact. For example, a data message produced and validated with a DSD version 1.1 is still valid against the same DSD (same id and Agency) upgraded to version 1.2.
40	40
...	...	@@ -46,16 +46,17 @@
46	46	* MINOR version when changes are backward but not forward compatible;
47	47	* PATCH version when minor changes (e.g. text clarifications, correction of typos) are both backward and forward compatible.
48	48
49		-**// //**b. Cost-benefit analysis for a major version change
	50	+== **// //**b. Cost-benefit analysis for a major version change ==
50	50
51	51	The cost of imposing a “major” change should be balanced against the benefit of retaining backward compatibility, for example by not deleting codes used in existing data exchanges or by deleting or replacing codes only through a concerted effort of all data exchange partners.
52	52
53		-| |**//c. Synthesis based on the above syntax and criterion//**|
54		-|(% colspan="2" %)**Change SeverityVersion ImpactDescription**|**Example**
55		-|(% colspan="2" %)**Major +.0 Neither** backward **nor** forward compatibility|**1.2 2.0**
56		-|(% colspan="2" %)**Minor N.+ **Backward **but not** forward compatibility|**1.0 1.1**
57		-|(% colspan="2" %)**Patch N.M.+ **Backward **and** forward compatibility|**1.2 1.2.1**
	54	+== c. Synthesis based on the above syntax and criterion ==
58	58
	56	+|(% colspan="2" %)**Change Severity**|**Version Impact**|**Description**|**Example**
	57	+|(% colspan="2" %)**Major**|**+.0**|__**Neither**__ backward __**nor**__ forward compatibility|**1.2 **→**2.0**
	58	+|(% colspan="2" %)**Minor**|**N.+**|Backward __**but not**__ forward compatibility|**1.0 **→**1.1**
	59	+|(% colspan="2" %)**Patch**|**N.M.+**|Backward __**and**__ forward compatibility|**1.2 1.**→**2.1**
	60	+
59	59	=== 4. Types of artefact changes and their versioning impact ===
60	60
61	61	As a general rule insignificant changes (e.g. textual clarifications or typos) will result in an increment of the patch component of the versioning system (i.e. N.M.**+**).