Versioning & Updates
Tome is a subscription to a live registry, but the code you pull from it is yours to keep. This page is the operational detail behind that: what keeps working when a plan lapses, what stops, and how versions move. The binding version of the promise lives in the Tome License; this page is the practical read.
What you've installed is yours
When you install a Tome package under an active plan, that version is yours to keep using — indefinitely. Committing it to your repository and vendoring it into a client's project doesn't put a clock on it. Nothing phones home; nothing gets remotely disabled. A site you shipped last year keeps running exactly as it did the day you shipped it, whatever happens to your subscription afterward.
What the subscription buys
An active subscription buys two things, and only two:
- New installs — pulling a package you're entitled to, for the first time, into a new project.
- Updates — pulling a newer version of a package you already have.
Both need a live connection to the registry and an active entitlement. Everything already installed or vendored keeps working without either. The registry proxy checks your live entitlement on each install — it's not a snapshot taken when the token was minted, so access reflects your plan as it stands right now.
If you cancel: the grace window
Cancelling stops future installs and updates — but not the instant your card lapses. Because a real build can race a failed payment or a mid-deploy cancel, there's a 14-day grace window: for 14 days after access ends, the affected bundles still resolve, so an in-flight npm install doesn't hard-fail. After the window, the install path returns the normal "not entitled" response.
The grace window only ever extends access briefly; it never reopens something that was shut for cause. It's anchored to when your access actually ended, so it's the same 14 days whether you hard-cancel or cancel at period end. And to be clear about the direction of the promise: grace protects your deploys, not your bill — nothing already installed was ever at risk.
Revoked vs. expired
There's a deliberate difference between a billing lapse and a security action:
| State | Cause | Grace? |
|---|---|---|
| Expired / cancelling | a subscription lapsed or was cancelled | Yes — the 14-day window applies |
| Revoked | a manual, security-driven kill | No — never graced |
A revoked token or entitlement is a security control, not a billing state, so grace never resurrects it. This is also why you can suspend or revoke an install token yourself from Account → Credentials the moment one leaks — suspend pauses it reversibly, revoke kills it for good, and neither waits on us.
Linked-family versioning
The block packs version as one linked family — they always release at the same version number, so a page built from several packs never lands on a mismatched set. Pin them together and upgrade them together. The family is:
@wabbit/tome-blocks(the meta-package) and@wabbit/tome-blocks-core- the pack bundles —
marketing-starter,content-writer,agency-essentials,editorial-pack,signal-theme,lms-pack,catalog-pack,org-pack, andextras
The capability layers — @wabbit/tome-core, @wabbit/tome-catalog, @wabbit/tome-economy, @wabbit/tome-lms, and the rest — version independently on their own semver, so upgrading a layer doesn't force the whole block family and vice versa. Follow their peer-dependency ranges when you bump one.
Releases & the changelog
Releases are changesets-driven: each change carries a changeset that decides the version bump and writes the notes, and the linked family moves as a unit at publish time. What shipped in each version lives on the changelog — check it before an upgrade to see what moved.
Reading this against the license
This page describes how versioning and access behave; the binding terms are in the Tome License. Refunds, support scope, and the registry's no-SLA / best-effort posture live in the license and on the Support and Continuity pages, not here. If the two ever seem to disagree, the license controls.