Versioning and releases

Adopted on 2026-10-31. The first release under this model is 26.2.0, which follows 0.1.0.

RavenRS follows the release model of commercial component vendors, adapted so that every version is also valid Cargo SemVer.

The version number: YY.R.P#

Commercial component vendors name releases the same way, such as 25.1 and 25.2, or 2025.1. The difference is that in RavenRS, 27.1 → 27.2 never breaks your build. ravenrs = "27" in Cargo.toml follows every feature and maintenance release of that year automatically. Breaking changes wait for the next year's .1 release, from 28.1.0 on: see below for what holds until then.

Calendar#

A breaking change can bring a YY.1.0 forward rather than slip into a feature release: 27.1.0 shipped in November 2026 for that reason. That was the last time: YY and R now follow the calendar only. Until 27.2.0, in the second half of 2027, every release is the next 27.1.P.

Until 28.1.0, any release may hold breaking changes, listed under Breaking in the CHANGELOG. The library is still taking shape, and holding its API still costs more than it saves. So until then ravenrs = "27" can break your build on cargo update: pin an exact version, ravenrs = "=27.1.8", if that matters to you. The table below is what holds from 28.1.0 on.

Each feature release has a public beta (YY.R.0-beta.N) about four weeks before the final release.

Support#

• The current year's line gets fixes. The previous year's line gets security and critical fixes for 12 months after the next major ships.
• MSRV. A feature release may raise the minimum Rust version to one at least six months old. A maintenance release never raises it.
• Deprecations are announced in a feature release with #[deprecated] and a replacement, and are removed no earlier than the next major.

What counts as breaking#

Breaking changes are the ones that Cargo SemVer and cargo semver-checks treat as major. Enums that grow are #[non_exhaustive], and builders have defaults, so new variants, fields and options are additions. Visual changes count too: a change that moves pixels in the golden-image tests ships only in a feature or major release, with a CHANGELOG entry.

Release checklist#

1. scripts/check.sh --full passes, including the golden-image tests.
2. cargo semver-checks runs against the previous release. Until 28.1.0, what it finds goes under Breaking in the CHANGELOG; from then on it has to agree with the version bump.
3. Benchmarks are within the budgets in QUALITY.md.
4. CHANGELOG has an entry, plus a migration guide for a major.
5. All crates are published in dependency order, then the tag vYY.R.P, the GitHub release, and the site and API docs are updated.
6. Every crate's documentation built on docs.rs (https://docs.rs/crate/<name>/<version>/status.json); it uses a recent nightly, so it can fail when stable passes.

Unified publication#

Framework crates, the cargo-ravenrs CLI, the RavenRS plugin and the npm preparer ship together under the same YY.R.P version. Every release publishes all public crates, the versioned Git tag, the npm package, API documentation and both documentation sites. CLI and npm-only fixes are included in the next complete release; do not report them as a complete RavenRS release. A different publication strategy requires an explicit request from Alex.

The CLI inherits the workspace version. npm/create-ravenrs/release.json pins that same version, cliVersion and vYY.R.P Git tag. Run prepare-release after the workspace bump; prepack rejects any mismatch in package versions, pins, toolchain or bundled licenses. Before publication, confirm the chosen version is unpublished on crates.io and npm, then follow the checklist above.

Historical npm 27.1.24–27.1.26 and CLI-only 27.1.24 kept framework 27.1.23. Starting with 27.1.27, all release artifacts are aligned again.