Versions are immutable
Once a version is published it cannot be changed. A bug in v1.2.3 is never silently patched — it is fixed in v1.2.4. This is intentional and important:
- You know exactly what you installed. The graph you wired last week still runs the same code this week.
- The changelog is the narrative. Every delta between versions is accounted for in the release notes, not buried in a silent overwrite.
- Yanked versions are labelled, not deleted. If a version has a critical defect the author can yank it — users see a clear warning, but the history remains visible.
Reading a changelog
Every version's changelog is split into three sections:
- Added — new capabilities, node kinds, MCP tools.
- Changed / Breaking — anything that may require you to update your graph or the minimum app version.
- Fixed — bug fixes that don't change the public contract.
A version with a breaking badge means it raises the minimum engine version or changes a node's wiring contract. Read the Changed section carefully before upgrading.
The version badge on a pack page
The recommended version badge shows the highest stable, non-yanked version that is compatible with the current engine. Compatibility is declared by the pack author as a semver range (e.g. >=1.0.0). If your app is older than the range minimum, the store will tell you.
Version history pages
Every pack has a /versions.html page — a full ledger from newest to oldest. Each entry shows:
- The semver string and its release date.
- The engine compatibility range.
- The full split changelog.
- A version-pinned install deeplink (coming soon) so you can install exactly that version, not whatever is latest.
For pack authors
When you cut a new release, the version you publish is locked. Think of it as tagging a git commit: you can push more commits, but you cannot rewrite the tag. Write your release notes before publishing — the store will display them verbatim, rendered from Markdown.
Use semver correctly:
- Patch (
1.2.3 → 1.2.4): bug fix only, no contract change. - Minor (
1.2.x → 1.3.0): new capability, backwards-compatible. - Major (
1.x.y → 2.0.0): breaking change, raise thecompatrange minimum.
Following this discipline means users can safely update to minor and patch versions without reading the changelog first — and know to pause at a major bump.