Context
Starlight supports versioned docs (multiple SDK version selectors) but the feature adds non-trivial complexity to the docs site. Resolution was: not relevant right now, track here instead.
What needs to happen
Revisit when one of the following triggers fires:
- SDK API changes meaningfully between versions after mainnet launch, such that docs-for-latest would misrepresent what older installs see.
- External builders pin to specific SDK versions and file confused issues because the docs only reflect HEAD.
- We ship a second major SDK version (v2.x) alongside v1.x and want to keep both sets of docs accessible.
Until then, the site stays unversioned (single-version, always reflects current SDK).
Deliverables when we pick this up
- Decide: Starlight's built-in versioning vs separate subdomain per version (e.g.
v1.docs.arkiv.network) vs URL-prefix (e.g. docs.arkiv.network/v1/...).
- Decide: how many prior versions we keep visible (latest only, latest + N-1, etc.).
- Plan: content migration — does every doc get copied into the versioned tree, or only API reference?
- Maintenance impact: who updates which version when a fix lands.
Links
Priority
Low. Open as deferred until one of the trigger conditions fires.
Context
Starlight supports versioned docs (multiple SDK version selectors) but the feature adds non-trivial complexity to the docs site. Resolution was: not relevant right now, track here instead.
What needs to happen
Revisit when one of the following triggers fires:
Until then, the site stays unversioned (single-version, always reflects current SDK).
Deliverables when we pick this up
v1.docs.arkiv.network) vs URL-prefix (e.g.docs.arkiv.network/v1/...).Links
Priority
Low. Open as deferred until one of the trigger conditions fires.