Difference between revisions of "Versioning of structural metadata artefacts"

From FMR Knowledge Base
Jump to navigation Jump to search
(Versioning Guidance)
Line 17: Line 17:
  
 
There are two generally adopted approaches.
 
There are two generally adopted approaches.
====Keep all structures at version 1.0====
+
====Option 1 - Keep all structures at version 1.0====
 
A simple method is to keep all structures at version 1.0. Changes are made as required but users of structures like DSDs may be surprised to find components have been added or removed unless other metadata governance procedures are in place.  
 
A simple method is to keep all structures at version 1.0. Changes are made as required but users of structures like DSDs may be surprised to find components have been added or removed unless other metadata governance procedures are in place.  
  
====Change
+
====Option 2 - Change version numbers to indicate significant changes have been made====
 +
For structures like Data Structure Definitions and Dataflows, versioning can be used to indicate to users when changes have been made that impact how they are used.
 +
 
 +
Data Structure Definition example versioning policy:
 +
{| class="wikitable"
 +
|-
 +
! Change !! Version
 +
|-
 +
| Change the DSD's description || The version number is not modified because the change has no material impact on the way the structure is used.
 +
|-
 +
| Add a new Attribute || Increment the minor version number, for instance moving from 1.0 to 1.1
 +
|-
 +
| A significant redesign of including adding and deleting multiple dimensions and attribytes || IIncrement the major version number, for instance moving from 1.1 to 2.0
 +
|}

Revision as of 03:45, 20 January 2021

Overview

All Maintainable structures have a mandatory version number of the form 1.0, 1.1, 2.3.

The version number defaults to 1.0.

The combination of the structure type, Agency ID, structure ID and version are used to uniquely identify any Maintainable structure using its URN.

Examples of URNs illustrating the use of version numbers:
urn:sdmx:org.sdmx.infomodel.codelist.Codelist=SDMX:CL_TIME_PER_COLLECT(1.11)
urn:sdmx:org.sdmx.infomodel.conceptscheme.Concept=IMF:ECOFIN_CONCEPTS(2.0).INDICATOR
urn:sdmx:org.sdmx.infomodel.datastructure.DataStructure=IMF:ECOFIN_DSD(1.0)
urn:sdmx:org.sdmx.infomodel.registry.ProvisionAgreement=WB:WDI_ENVIRONMENT_WB_WB(1.0)

Versioning Guidance

SDMX does not mandate a versioning policy. Organisations maintaining their own structures are therefore free to choose how and when version numbers change.

There are two generally adopted approaches.

Option 1 - Keep all structures at version 1.0

A simple method is to keep all structures at version 1.0. Changes are made as required but users of structures like DSDs may be surprised to find components have been added or removed unless other metadata governance procedures are in place.

Option 2 - Change version numbers to indicate significant changes have been made

For structures like Data Structure Definitions and Dataflows, versioning can be used to indicate to users when changes have been made that impact how they are used.

Data Structure Definition example versioning policy:

Change Version
Change the DSD's description The version number is not modified because the change has no material impact on the way the structure is used.
Add a new Attribute Increment the minor version number, for instance moving from 1.0 to 1.1
A significant redesign of including adding and deleting multiple dimensions and attribytes IIncrement the major version number, for instance moving from 1.1 to 2.0