1. Versioning

Rails follows a shifted version ofsemver:

PatchZ

Only bug fixes, no API changes, no new features.Except as necessary for security fixes.

MinorY

New features, may contain API changes (Serve as major versions of Semver).Breaking changes are paired with deprecation notices in the previous minoror major release.

MajorX

New features, will likely contain API changes. The difference between Rails'minor and major releases is the magnitude of breaking changes, and usuallyreserved for special occasions.

2. New Features

New features are only added to the main branch and will not be made availablein Patch releases.

3. Bug Fixes

Minor releases will receive bug fixes for one year after the first release inits series. For example, if a theoretical 1.1.0 is released on January 1, 2023, itwill receive bug fixes until January 1, 2024. After that, it will be consideredunsupported.

Bug fixes are typically added to the main branch, and backported to the x-y-stablebranch of the latest release series if there is sufficient need. When enough bugsfixes have been added to an x-y-stable branch, a new Patch release is built from it.For example, a theoretical 1.2.2 Patch release would be built from the 1-2-stable branch.

For unsupported series, bug fixes may coincidentally land in a stable branch,but won't be released in an official version. It is recommended to point yourapplication at the stable branch using Git for unsupported versions.

4. Security Issues

Minor releases will receive security fixes for two years after the first release inits series. For example, if a theoretical 1.1.0 is released on January 1, 2023, itwill receive security fixes until January 1, 2025. After that, it will reach itsend-of-life.

These releases are created by taking the last released version, applying thesecurity patches, and releasing. Those patches are then applied to the end ofthe x-y-stable branch. For example, a theoretical 1.2.2.1 security release wouldbe built from 1.2.2, and then added to the end of 1-2-stable. This means thatsecurity releases are easy to upgrade to if you're running the latest versionof Rails.

Only direct security patches will be included in security releases. Fixes fornon-security related bugs resulting from a security patch may be published on arelease's x-y-stable branch, and will only be released as a new gem inaccordance with the Bug Fixes policy.

Security releases are cut from the last security release branch/tag. Otherwisethere could be breaking changes in the security release. A security releaseshould only contain the changes needed to ensure the app is secure so that it'seasier for applications to remain upgraded.

5. End-of-life Release Series

When a release series reaches its end-of-life, it's your own responsibility todeal with bugs and security issues. We may provide backports of the fixes andmerge them, however there will be no new versions released. Werecommend to point your application at the stable branch using Git. If you arenot comfortable maintaining your own versions, you should upgrade to a supportedversion.

6. Release schedule

We aim to release a version containing new features every six months. In the rare case whereno release was made in one year, we will extend the support period for the previous releaseuntil the next release is made.

7. npm Packages

Due to a constraint with npm, we are unable to use the 4th digit for securityreleases ofnpm packages provided by Rails. This means that instead of theequivalent gem version7.0.1.4, the npm package will be versioned7.0.104.

The version will be calculated asX.Y.Z0A, whereA is the security release.