Versioning policy

This page has two halves: how the tool is released, and how these docs are versioned alongside it.

Release tags

A release is a v<semver> Git tag. The current release is v1.1.0, after v1.0.0 to v1.0.3 and the v0.2.x line. This documentation set is version 1.0. It was written against v0.2.5 and is to be re-verified against the released tool; the space creation pages are written ahead of the next tag (Changelog).

One tag publishes native binaries for:

• linux/amd64, linux/arm (32-bit ARMv7, including Raspberry Pi OS armhf), and linux/arm64
• darwin/amd64 and darwin/arm64
• windows/amd64

They ship together with a strict SHA256SUMS file and the license NOTICE. Asset names follow slivingdoc-v<semver>-<os>-<arch>, with .exe on Windows.

The npm package slivingdoc is a launcher rather than a copy of the binary. It selects the asset for its exact version and platform, verifies the published SHA-256, caches the verified bytes, and forwards stdio to the child process. An unsupported platform fails before any download, with an actionable error. See Installation.

A prerelease tag — v1.2.3-rc1, for example — publishes to the next npm dist-tag. A stable tag publishes to latest.

Publication order

The order is enforced, not conventional:

1. The tag builds every target and assembles the GitHub release.
2. The npm publish job runs only after the release job, which is what orders them. npm run check-release runs as a guard before npm publish: it sends one HEAD request per required artifact and fails if any is missing. It does not wait for the release to complete.
3. The same tag then publishes the npm launcher automatically.
4. Only after that does the MCP Registry job publish the checked-in server.json card, because the Registry can verify ownership only once the matching npm package version is public. The version may not be readable the moment npm publish returns, so the job first polls the npm registry every 30 seconds, for up to 15 minutes, then validates the card and submits it, retrying the submission up to three times, 60 seconds apart.

Publication uses npm trusted publishing (OIDC): the repository stores no npm token and no Registry token, and provenance relies on the attestation that npm trusted publishing adds by default; no provenance flag is passed. The Registry card’s server version and the npm package version always move together.

What is stable across releases

The tool’s architecture contract names exactly what a caller may depend on:

• The error code, reason, and action tokens, and every files[].reason token, are stable. Message text can change. See Errors.
• The storage format is versioned in the manifest itself: a future incompatible or extended schema uses a different version, and a version 1 reader rejects it before touching a pack. MCP callers do not depend on the internal representation at all.

Beyond that, the published sources make no compatibility promise, and neither does this page. The tool is pre-1.0.

How these docs are versioned

A docs version is one tool minor release. Two exist today: 0.1, archived and frozen, and 1.0, the latest. Version 1.0 does not follow the rule exactly. It was cut from 0.1 because the tool’s behaviour outgrew the 0.1 set during the v0.2.x line, ahead of the v1.0.0 release it is named for, so it documents v0.2.5 until that re-verification, plus the space creation pages. Read “docs 1.0” as the docs version, not the tool’s: the tool is at v1.1.0.

• Latest lives at the plain URL. /docs/… is always the newest version. Bookmarks and links to a page keep pointing at its current form.
• Archived versions get a prefix. When a version is cut, the old set moves to /docs/v<label>/… and stays there, frozen.
• An archived page says so. It carries a banner linking to the latest version of the same page, and declares that latest page as canonical for search engines when one exists.
• Archived pages are excluded from the site search and from the /llms.txt and /llms-full.txt indexes, so neither a person nor an agent lands on a stale page by accident. They still have a Markdown representation like every other page.

Changes inside one version are listed on the Changelog.