eProcurement Ontology Versioning Rules

In this section, we outline the versioning rules for the eProcurement ontology, specifically focusing on when to increment major, minor, and patch versions. Understanding these rules is essential for effectively managing and updating ontologies, as well as maintaining compatibility with applications and SPARQL queries. By adhering to these guidelines, developers and maintainers can ensure smooth transitions between different versions and minimise potential disruptions to dependent systems.

Semantic versioning in a nutshell

“Dependency hell” plagues software management and impacts models, architecture and documentation. As a project expands, the complexity of changes and dependencies increase, complicating the release of new work packages. Version lock and version promiscuity impede progress, making it difficult to move projects forward safely and efficiently.

Semantic Versioning offers a solution by providing a set of rules for assigning and incrementing version numbers. It clearly communicates changes in artefacts through version number increments and change notes using the X.Y.Z (Major.Minor.Patch) format:

  • Bug fixes increment the patch version,

  • Backwards-compatible changes increment the minor version, and

  • Backwards-incompatible changes increment the major version.

This approach provides numerous benefits:

  • Precise artefact version identification

  • Traceable artefact evolution for governance

  • Minimised client-side impact from artefact changes

  • Prevention of accidental semantic-level compatibility breaks

  • Effortless detection of version incompatibility

  • Clear differentiation of impact and compatibility levels for changes

  • Transparent artefact evolution timeline

  • Manageable artefact version governance (e.g., approval processes, quality gates, parallel versions, branches)

Major version increment

  • A class, attribute, or relation is deleted.

  • A class, attribute, or relation’s URI is changed.

Implications:

  • Applications must be aware of major releases and should not use them unless specifically designed to support them.

  • If the ontology changes impact an existent SPARQL query, the major version number must be incremented.

Minor version increment

  • A new attribute, relation, or class is added.

Implications:

  • Applications can continue using the ontology, but will not be able to utilise the new features.

  • A minor change occurs if the SPARQL query works but does not refer to the new classes or properties.

Patch version increment

  • Any other modification, such as, terminological changes, updates to the definitions or labels.

Implications:

The updated ontology can safely replace the previous version without affecting the functionality of applications or queries.

Release labelling

  • Pre-release (unstable) versions should be labelled with the suffix "-beta.#" (where # stands for a number e.g. 1,2,3).

  • Release candidate (stable) versions should be labelled with the suffix “-rc.#” (where # stands for a number e.g. 1,2,3). Release candidate versions are issued to allow stakeholders to test and provide final remarks.

This helps track unstable, in-development and release candidate versions, but does not impact precedence.

Conclusion

By following the versioning rules outlined in this section, ontology developers and maintainers can effectively manage versioning and ensure a smooth transition between different versions of the ontology. These rules provide clear guidelines for when to increment major, minor, and patch versions, considering the potential impact on applications and SPARQL queries. Adhering to these rules will help minimise disruptions and maintain compatibility across various systems that rely on the ontology.

Any comments on the documentation?

Click here to let us know