[AIXM-343] AIXM version naming policy

Description

A version naming policy is formally established for AIXM, to be applied starting with version 5.2.

Rationale for change

See https://aixmccb.atlassian.net/browse/AIXM-278 

Following a coordination effort with the Flight Information Exchange Model (FIXM) CCB (see Version policy) a common version numbering policy has been agreed. This is relatively similar to the AIXM version numbering policy already applied up to version 5.1.1. The most important difference is in the naming - a ‘regular update’ (such as AIXM 5.2) will now become a ‘minor version’ and a ‘minor version’ (such as AIXM 5.1.1) will now be named a ‘patch version’.

Impact assessment

AIXM 5.1.1 Data Providers and Data Users will not be impacted by this proposal since there is no change in the XML schema.

Change Proposal details

‘Semantic versioning 2.0.0’ is used as a common reference: MAJOR.MINOR.PATCH.

A MAJOR (X.y.z) version introduces major conceptual changes. Forward data mapping is not guaranteed. The changes justifying a new MAJOR release include, but are not limited to:

• Refactoring a large part of the model
• Scope reduction of the –XM / deletion of model elements without prior deprecation or replacement
• Use of a different data encoding syntax, or withdrawal of a given physical realization of the –XM Logical Model

Example: AIXM 5.0.0 significantly revisits the modelling of geometrical and geographical data, being based on the Geography Markup Language.

A MINOR (x.Y.z) version introduces new model elements and capabilities guaranteeing forward data mapping for non-deprecated elements or deprecated elements with replacement. Loss of information may happen for elements being no longer required. The changes allowed in a MINOR release include, but are not limited to:

• Inclusion of new model elements, in particular in support of evolving ICAO requirements (e.g. SARPS update)
• Deprecation of model elements, with or without replacement
• Deletion of model elements deprecated in a previous version
• Addition of a new physical realization of the –XM Logical Model

Example: AIXM 5.2.0 will facilitate, among others, the provision of ICAO data sets (except for terrain data) as specified in the new Annex 15 & PANS-AIM and the data provision for emerging concepts such as free routes, large-scale use of RPAS.

A PATCH (x.y.Z) version is limited to bug fixing. Forward and backward data mapping is guaranteed without loss of information. A PATCH version does not impose changes in a consuming system. A PATCH version may still require data conversion to be made ahead of the data entering in the consuming system (done by a mediator service). The changes allowed in a PATCH release include, but are not limited to:

• Clarification of definitions, changes to the –XM documentation package and/or to the -XM Logical Model with no impact on the physical realization(s).
• Correcting spelling mistakes, incl. in physical realisations
• Updating external references

Example: AIXM 5.1.1 moves the maintenance of the AIXM UML model to a new modelling environment and corrects a few bugs.

Alpha, Beta or Release Candidate versions, if created, will be named as follows:

• X.Y.Z_ALPHA
• X.Y.Z_BETA
• X.Y.Z_RC

An optional increment may be added in order to distinguish between multiple ALPHA, BETA or RC versions (e.g. X.Y.Z_RC2)

NOTES & CLARIFICATIONS

• For the -XMs, the notion of backward/forward compatibility is to be understood from a data mapping point of view. Two consecutive versions are considered backward (resp. forward) compatible if backward (resp. forward) data mapping is enabled.

Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

Not applicable.

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

Not applicable.

Mapping example

Not applicable.