Versioning Every Helix package shares one version. @fusion.dev/helix@1.4.0 works with @fusion.dev/helix-headless@1.4.0 and with @fusion.dev/helix-styles@1.4.0. This is guaranteed, because we always release them together, from one tag. bun add @fusion.dev/helix@1.4.0 @fusion.dev/helix-styles@1.4.0 Pin every Helix package to the same version, or pin none of them. The one setup this versioning does not protect you from is a range that lets one package move ahead of another. Why Helix packages share one version Cortex has its own version. We did not give every package in the repository one version, because the documentation packages carry the version of what they document. With one version for everything, a Cortex fix would publish a new version of @fusion.dev/helix-docs in which nothing about Helix changed. One version for Helix keeps the property that matters. Two Helix packages with the same version were tested together. The version number comes from the Git tag CI computes each version from the Git tags and writes it into every package manifest seconds before packing. Once the release is promoted, CI commits the same number back to main. The version in each Helix package.json in the repository is therefore the last release, and the tag is the record it copies. The Rust crates stay at 0.0.0-dev. The helix binary reports the version of the npm package it was installed with. Releases use two kinds of tag: TagMeanshelix-v1.4.0A release that promotedhelix-attempt-v1.4.0A number that was spent and did not ship The next version is computed from both kinds of tag. A failed release uses up its number, and the next release gets a new one. If you see that 1.4.0 was skipped, a release with that number failed. Documentation is versioned with the code @fusion.dev/helix-docs@1.4.0 documents Helix 1.4.0. The package documents one version and has no version switcher. Its version number is the Helix version it documents, because every Helix package shares one version. To serve documentation for several versions, install several versions of the package. npm already supports this, and it is the only approach that cannot fall out of step with the code. Stability Each component has a status in the manifest and on its page. The status is one of: experimental stable deprecated Most components are stable. These families are experimental, and their status says so: the spatial charts, which draw in three dimensions Log Strands Motion Toggle We will not change a status to make the library look more finished than it is. Release notes Release notes are on GitHub, generated from the tags. Helix has no changelog file. A second copy of the release notes would have to be kept in step with the first, and the copy nobody reads that week is the one that goes stale.