Versioning, compatibility and deprecation
Development status: Status and changes — As of this page’s date there are no releases, protocol or software versions, release channels, compatibility promises or deprecations. The experimental implementation is evidence only for its own limited scope; it is not a release and carries no compatibility or support commitment. No release plans or dates are published, and nothing is publicly available for live use.
Before you read: Availability and changes.
Which version does this documentation describe, and what compatibility or deprecation commitments exist? No version, because no release exists, and no commitments. This page explains how documentation revisions relate to protocol versions, what compatibility would mean once releases exist, how versions, deprecations and migrations would be documented, and how to plan in the meantime. It contains no version numbers, dates or channels.
The short answer
No release exists, so this documentation describes no protocol or software version; it describes intended capabilities as of each page’s date. No release channel, support period, compatibility promise or deprecation is published.
The experimental implementation is evidence only for its own limited scope. It is not a release, and it carries no compatibility or support commitment. No release plans or dates are published.
Documentation revisions versus protocol versions
The documentation is revised independently of any protocol or software version. Instead of a version number, each page shows an as-of date and a next-review date; Documentation conventions: status labels, dates and reviews explains both.
Changes to the documentation are recorded in the Documentation change log. There are no protocol release notes, because there are no releases. A page’s status label describes the maturity of a capability, not a version.
What compatibility would mean
Once releases exist, compatibility could refer to any of the following:
- Interface compatibility — applications written against one version of an interface keep working with a later one.
- Network compatibility — nodes running different software versions can keep working together.
- Data compatibility — recorded state and stored data remain readable after upgrades.
- Tool compatibility — which versions of tools, such as SDKs, work with which versions of interfaces and networks.
None of these is promised today, and no compatibility with other platforms’ interfaces, formats or conventions is claimed.
How versions, deprecations and migrations would be documented
Status of this section: Planned — these practices describe the intended documentation for when releases exist; none is in effect, and none is a commitment.
- Each release would carry a version identity, shown on every page that documents released behaviour.
- Compatibility statements would be published with each release — for example, as a table of which tool, interface and network versions work together.
- Deprecation notices would state what is deprecated, from which version, what replaces it and how long it would remain available.
- Migration guides would accompany changes that require action by developers or operators.
- Release notes would open with the versions they cover.
Protocol upgrades themselves are intended to be introduced in stages, a design that is being explored; see Time-delayed execution and staged upgrades.
Planning around versioning today
- Do not depend on the experimental implementation or its interfaces: they are internal and will change. Interfaces and their status describes the status of each interface family.
- Keep the part of an application that talks to the network separate, so that it can adapt to versioned reference when it appears.
- Record the as-of dates of the pages your design assumptions come from, and check the change log for later changes.
Assumptions, trust and limitations
The practices above are intentions for when releases exist. They may change, and none is a support or compatibility commitment.
Not yet available, and how this page will grow
When a first release exists, this page would state its version identity, support status and compatibility statements, and would list deprecations and migrations with their versions. If a reviewed statement about release plans is approved, it would be published on the status hub and recorded in the change log.
What this page does not claim
This page does not claim any version, release date, release channel or support period; any compatibility or deprecation commitment; or any compatibility with other platforms. Anything not stated here as available should be treated as unavailable.
Related pages
- Documentation change log — dated documentation changes, kept separate from any future release notes.
- Documentation conventions: status labels, dates and reviews — as-of and next-review dates in place of versions.
- Interfaces and their status — interface families whose reference would be versioned once released.
- Time-delayed execution and staged upgrades — the intended staging of protocol upgrades.
Glossary
References
No approved public references yet.
