Stability and releases

• Semantic versioning, staying on 2.x. Nothing in 2.x breaks existing code: new behaviour is opt-in, defaults don't change, and the TypeScript API and the Rust API are checked against the previous release in CI (api/rust-fetch.d.ts, cargo-semver-checks). A breaking change would wait for 3.0, with a migration guide and at least one 2.x release warning about it first.
• Fewer, larger releases. 2.0 to 2.5 shipped within three days in October 2026, while the project was getting started. From 2.6.0, minor releases come at most every two weeks. Patch releases are only for regressions and security fixes, each with a test that reproduces the problem.
• What gets fixed. The latest 2.x minor release gets bug and security fixes. Security issues are handled privately, as described in SECURITY.md.
• How a release is checked. Every release is built and published from CI with npm provenance, after the Rust and JavaScript suites (100% line coverage enforced for the Rust core and the Node.js transport), real-browser tests in Chromium, Firefox and WebKit, the security regression tests, and the size and API checks. Each pull request is also benchmarked against the previous version. Before publishing, the exact tarball npm will receive is installed in an empty directory and checked: its files, a request against a local server, the security regression tests, and a benchmark against the version already on npm, where a regression stops the release (check-package.mjs). After publishing, a clean install from the registry must verify its signature and provenance. CI's GitHub Actions are pinned to commit SHAs, and its Rust to a fixed version.
• What changed and why. CHANGELOG.md lists every change, including performance regressions and their fixes (2.4.1), and ROADMAP.md shows what's next.