Lifecycle & versioning policy
Semantic versioning rules, deprecation timelines, and retirement policy — including how to handle external regulatory withdrawals (the NTS situation).
Status
This is a stub for upcoming work. The structure below is what we plan to populate; existing artefacts in source/ that feed it are cited inline.
What already exists
source/03-standards/trust-framework/docs/release-version-register.md— version log- Schemas use semantic versioning (MAJOR.MINOR.PATCH). Currently v3.4 stable, v3.6 in development.
- Older overlay versions kept for backward compat in
v3/overlays/:baspi4,nts,ntsl.
Policy questions to resolve
- How long is N-1 supported? When v4 ships, how long does v3 stay supported?
- Deprecation marking — JSON Schema deprecation keyword + machine-readable sunset date
- What happens when an upstream form is withdrawn? (the NTS case — successor is months away from MHCLG)
- Major-version cadence — how often? Annual? Driven by demand?
- Per-overlay vs whole-framework versioning — overlays evolve independently from the base
Worked case study: NTS overlay retirement
NTS withdrew the Material Information v1.0 guidance in late 2025 (DMCC Act 2024 superseded the underlying regulation). OPDA's nts.json and ntsl.json overlays implement guidance that is no longer authoritative — but firms using them are still operating compliantly under the transitional arrangements.
The lifecycle policy needs to define:
- Mark
nts.jsonas deprecated in the schema (not yet retired) - Track MHCLG's successor publication (Oct 2025 consultation)
- When MHCLG publishes, ship a new
mhclg-material-info.jsonoverlay - Sunset date for the old NTS overlay: 6 months after MHCLG go-live
See source/08-external-references/nts/README.md for the full context.