Versioning and Releases

ByteOr documentation versions by platform release line. The public hub, synced repo docs, and same-site rustdoc should move together so readers do not have to guess which contract matches which release.

One rule for the platform

  • The central byteor-docs site versions by platform release line, not by individual crate publication cadence.
  • Each release line lives under its own docs directory, for example docs/v0.1/.
  • The default release line stays unprefixed in the public route surface.
  • With only one configured release line, the default Rspress theme does not render a visible version switcher. In that state, this site shows the current release line inside the far-left header title pill, while search is styled to match it as a paired utility control. The switcher appears once a second version is added to the configured release list.
  • Older release lines remain browsable through Rspress multi-version navigation.

Linking model

  • Keep internal site links authored as normal site-relative routes such as /cloud/ or /reference/repo-docs-index.
  • Do not hard-code /v0.1/ or /v0.2/ into shared nav, sidebar, or in-site prose links.
  • The release line configured as defaultVersion stays at the unprefixed route surface.
  • Non-default release lines get the version prefix, for example /v0.2/cloud/.
  • When the default release line changes, the unprefixed route surface moves with it and older release lines remain under their explicit version prefixes.

For this project, the normal practice is to make the latest stable release line the default version. That keeps public entry routes stable while still preserving older docs under explicit versioned paths.

Repo-owned outputs

  • ByteOr OSS, IndexBus, and ByteOr Enterprise should publish rustdoc per release line.
  • Repo-owned public docs source should be snapshotted alongside release tags before being synced into the central site.
  • ByteOr Cloud follows the same public-doc snapshot rule, but rustdoc is not currently part of the public surface.

Expected repo URL shape

  • latest synced repo docs remain at routes such as /reference/repo-docs/oss/
  • release-line snapshots should be staged under paths such as /v0.1/
  • immutable tag snapshots should be staged under /releases/<tag>/ when release artifacts are preserved publicly
  • repo-owned rustdoc should remain at /rustdoc/<repo>/ for latest and /rustdoc/<repo>/<release-line>/ for release-line snapshots

Release discipline

When a release line changes, update these together:

  1. repo-local public docs bundles
  2. published rustdoc for the relevant Rust workspaces
  3. central-site generated synced repo-doc pages
  4. central-site hand-authored links and version metadata

Practical rule

Do not create docs versions as loose folder copies outside the framework model. Add the release line explicitly to the Rspress multi-version config, keep internal links version-agnostic, and keep release checklists aligned across the repos.

Provenance
Need the canonical source?
Use the public hub to orient yourself, then jump to repo-owned docs or rustdoc when you need contract-level detail.