Release versioning & retirement

    How versions identify OPDA artefacts, and the remaining policy decisions for compatibility, deprecation, support windows and retirement.

    Two related policies, kept separate

    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.

    ArtefactCurrent corpus evidenceSource
    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

    1. Support window. How long is the previous major version supported after its successor ships?
    2. Machine-readable deprecation. How are deprecation and sunset dates represented across ontology, schema, API and documentation?
    3. Independent artefacts. Which artefacts version independently, and which versions must be released as one coherent pack?
    4. Migration evidence. What implementation proof is required before a major version or retirement date is ratified?
    5. 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.

    No retirement date has been ratified

    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…