augmanitai

AUGMANITAI Versioning Policy

AUGMANITAI uses Semantic Versioning 2.0.0 (https://semver.org/), adapted for a terminology database. This document explains what MAJOR, MINOR, and PATCH mean specifically for a project whose primary artifact is a curated vocabulary rather than executable software.

Version Format

MAJOR.MINOR.PATCH (e.g., 1.2.3)

Optional suffixes: -alpha.N, -beta.N, -rc.N for pre-releases; +BUILD for build metadata.

Scope of Versioning

A single version number covers the entire release of:

  1. Terminology data — the JSON/RDF/SKOS/TBX/JSON-LD exports of terms and relations.
  2. Code — the Python package, NPM package, MCP server, API mock, helpers.
  3. Protocols — the exposed MCP/A2A/ANP/AG-UI interfaces.
  4. Documentation — the handbook, term pages, API reference.

Sub-components may have their own internal versions for debugging purposes, but the published version is the compendium version.

MAJOR (X.y.z)

A MAJOR version increment signals a breaking change for consumers. For AUGMANITAI, this includes any of:

Terminology breaking changes

Code breaking changes

Schema breaking changes

Migration support

MAJOR releases ship with a MIGRATION.md that documents every breaking change and provides copy-pasteable fixes where possible.

Terms removed in a MAJOR release are never reused: their IDs are permanently retired and their URIs resolve to a tombstone with a prov:invalidatedAtTime timestamp and a pointer to the replacement (if any).

MINOR (x.Y.z)

A MINOR version increment signals backward-compatible additions. For AUGMANITAI, this includes:

Constraint: a MINOR release must not change the meaning of any existing term or API in a way that existing consumers would notice.

PATCH (x.y.Z)

A PATCH version increment signals fixes that do not change meaning. For AUGMANITAI, this includes:

Constraint: a PATCH release must not add or remove any term, field, or API. If you find yourself adding something in what you thought was a PATCH, it is actually a MINOR.

Pre-releases

Pre-releases may be published on Zenodo as separate DOI entries (each Zenodo upload gets its own DOI; the “concept DOI” is the version-independent one).

DOI Policy

Citations should cite the version DOI for reproducibility and the concept DOI for “latest” references.

Deprecation Policy

Before removing a term or API in a MAJOR release, it must be deprecated in at least one prior MINOR release.

A deprecated term:

A deprecated API function:

Version Communication

Each release is accompanied by:

  1. A CHANGELOG.md entry (Keep a Changelog format)
  2. A git tag (v1.2.3) signed with the maintainer’s GPG key or Sigstore
  3. A GitHub/GitLab Release
  4. A Zenodo upload with full metadata
  5. An announcement on the project’s official channels
  6. For MAJOR releases: a MIGRATION.md and a retrospective blog post

Example Scenarios

Change Version bump
Add new term “Context Collapse” MINOR
Fix a typo in the definition of SLE PATCH
Add Chinese translation for RKE MINOR
Rename term SSP to SEMPROG MAJOR
Remove the experimental AIPS-v2 term MAJOR
Add new relation type aug:derives-from MINOR
Tighten the SHACL shape to require dct:created on all terms MAJOR (if existing data would fail) / PATCH (if it already passes)
Add a new list_terms_by_year() API function MINOR
Change default return type of lookup() from dict to dataclass MAJOR
Speed up search() with a better index (same results) PATCH

Bound by the Ethical Disclaimer §1–§20 (DISCLAIMER.md) and the repository licenses (LICENSE). Contact and provider: IMPRESSUM.md.