Release versioning & retirement
How versions identify OPDA artefacts, and the remaining policy decisions for compatibility, deprecation, support windows and retirement.
This page covers versions and retirement of released artefacts. The proposed route by which evidence and candidates become a ratified release is documented separately in How OPDA develops and approves standards. ADR-0068 is not yet operative.
Current version domains
The current standards stack carries separate artefacts on separate version tracks. They do not automatically share a release cadence or support window.
| Artefact | Current corpus evidence | Source |
|---|---|---|
| PDTF schemas | Version 3.5.0; the package describes semantic versioning. | @pdtf/schemas package |
| Trust framework | Version 0.3.0; still pre-1.0. | @pdtf/trust-framework package |
| API specification | Definitions include 1.1.0, 1.2.0, 1.3.0 and 2.0.0. | source/03-standards/api/ |
Older baspi4, nts and ntsl overlay versions remain
in the v3 corpus for compatibility. The existing
release-version register
records released versions, but a complete support and retirement policy has not yet
been ratified.
Semantic versioning in the current schema corpus
- PATCH — fixes that do not introduce a breaking change.
- MINOR — backward-compatible additions.
- MAJOR — breaking changes that require migration.
That convention identifies the compatibility impact of a schema release. It does not, by itself, prove consensus, public review, implementation evidence or ratification.
Policy still to be decided
- Support window. How long is the previous major version supported after its successor ships?
- Machine-readable deprecation. How are deprecation and sunset dates represented across ontology, schema, API and documentation?
- Independent artefacts. Which artefacts version independently, and which versions must be released as one coherent pack?
- Migration evidence. What implementation proof is required before a major version or retirement date is ratified?
- Upstream withdrawal. What happens when a law, form or external standard on which an artefact depends is replaced or withdrawn?
Case study: withdrawn NTS guidance
The NTS Material Information guidance was withdrawn after the underlying regulatory
position changed. OPDA still carries
nts.json
and
ntsl.json
because implementations may remain in transition. The future policy needs to distinguish
deprecated, superseded and withdrawn, publish
the reason, identify any successor and define a justified sunset date.
A previous working proposal suggested sunsetting the old NTS overlay six months after successor guidance goes live. That remains a proposal, not policy. See the NTS evidence note for the source context.
Relationship to the proposed standards lifecycle
If ADR-0068 is accepted, a compatible substantive change would normally produce a minor release; a breaking or material change would require full public review, implementation evidence, a migration/deprecation plan and major-version ratification. Released artefacts would be immutable, historical versions would remain available, and each OPDA Standard would receive a systematic review at least every 24 months.
Comments
Loading comments…
Sign in to post a comment