Annex: Versioning approach proposed by the DT DS in 2010 in "INSPIRE Maintenance and Implementation – Discussion Paper"¶
The following system for revisions is proposed (mainly based on the new approach being recently developed within OGC) for INSPIRE Guidance documents.There are three different types of changes, expressed in different levels of version numbers. Versions are described by a three-level version number X.Y.Z, e.g. 1.2.1.
The three levels of changes are:
- Corrigendum (Z): A pure bugfix release that replaces the previous X.Y.(Z-1) version. The previous version should not be used any longer as it is broken. All data providers and software vendors need to update to the new corrigendum. No semantic changes are allowed.
As a corrigendum does not change any semantics it is not appropriate to apply the methodology or involve all stakeholders in the process, i.e. there should be a simpler mechanism to develop and adopt the corrigendum.
Examples for changes:
- A technical error in an XML Schema was detected that leads to validation errors.
- An attribute with an error in the multiplicity
- The definition of a spatial object type is inconsistent with the FCD at the time of adoption of the data specification.
A major error should immediately lead to a corrigendum. Smaller errors may be collected first and introduced in the next corrigendum.
- Minor revision (Y): A backwards compatible revision, i.e. all data sets conforming to version
X.(Y-1).Z still conformant with revision X.Y.0. This should be the typical approach for revisions unless fundamental changes are required.
This has some implications on the types of changes that may be applied in a minor revision. In particular, outdated items are marked as deprecated but kept in the specification.
Examples for changes are the introduction of a new spatial object type, a new attribute in a spa-tial object type or a new listed value in an enumeration.
- Major revision (X): A revision introducing significant changes. Where feasible and appropriate, a major revision may also still be backwards compatible. This type of revision should only be targeted if absolutely necessary for the domain, e.g. to introduce a significant number of additional spatial object types to a theme, or if there is consensus to upgrade the Generic Conceptual Model or a data specification in a fundamental, incompatible way.
Besides explicit change requests from submitting organisation, it might be considered to periodi-cally, e.g. every six years, ask Member States for requirements for changes to the adopted data specifications. A similar process is used within ISO.
The types of changes that are possible / applicable in each of the versions should be described in more detail (once there is a general agreement on the classification system).
It should be discussed if the encoding(s) of a data specification are versioned separately from the data specification itself, to decouple conceptual issues from technical issues on different encoding platforms.