Implement new maintenance policy

Main changes are:

* Releases are maintained by a pre-defined, fixed period of time.
  One year for bug fixes and two years for security fixes.

* Distinction between severe security issues and regular security issues
  is removed.

* Npm versioning is updated to match not use the pre-release `-`
separator.

Author: rafaelfranca

guides/source/maintenance_policy.md

@@ -3,8 +3,8 @@
 Maintenance Policy for Ruby on Rails
 ====================================
 
-Support of the Rails framework is divided into four groups: New features, bug
-fixes, security issues, and severe security issues. They are handled as
+Support of the Rails framework is divided into three groups: New features, bug
+fixes, and security issues. They are handled as
 follows, all versions, except for security releases, in `X.Y.Z`, format.
 
 --------------------------------------------------------------------------------
@@ -35,31 +35,32 @@ New Features
 ------------
 
 New features are only added to the main branch and will not be made available
-in point releases.
+in Patch releases.
 
 Bug Fixes
 ---------
 
-Only the latest release series will receive bug fixes. Bug fixes are typically
-added to the main branch, and backported to the x-y-stable branch of the latest
-release series if there is sufficient need. When enough bugs fixes 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.
+Minor releases will receive bug fixes for one year after the first release in
+its series. For example, if a theoretical 1.1.0 is released on January 1, 2023, it
+will receive bug fixes until January 1, 2024. After that, it will be considered
+unsupported.
 
-In special situations, where someone from the Core Team agrees to support more series,
-they are included in the list of supported series.
+Bug fixes are typically added to the main branch, and backported to the x-y-stable
+branch of the latest release series if there is sufficient need. When enough bugs
+fixes 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 your
 application at the stable branch using Git for unsupported versions.
 
-**Currently included series:** `8.0.Z`.
-
 Security Issues
 ---------------
 
-The current release series and the next most recent one will receive patches
-and new versions in case of a security issue.
+Minor releases will receive security fixes for two years after the first release in
+its series. For example, if a theoretical 1.1.0 is released on January 1, 2023, it
+will receive security fixes until January 1, 2025. After that, it will reach its
+end-of-life.
 
 These releases are created by taking the last released version, applying the
 security patches, and releasing. Those patches are then applied to the end of
@@ -78,32 +79,28 @@ there could be breaking changes in the security release. A security release
 should only contain the changes needed to ensure the app is secure so that it's
 easier for applications to remain upgraded.
 
-**Currently included series:** `8.0.Z`, `7.2.Z`.
-
-Severe Security Issues
-----------------------
-
-For severe security issues all releases in the current major series, and also the
-last release in the previous major series will receive patches and new versions. The
-classification of the security issue is judged by the core team.
-
-**Currently included series:** `8.0.Z`, `7.2.Z`.
-
-Unsupported Release Series
+End-of-life Release Series
 --------------------------
 
-When a release series is no longer supported, it's your own responsibility to
+When a release series reaches its end-of-life, it's your own responsibility to
 deal with bugs and security issues. We may provide backports of the fixes and
 merge them, however there will be no new versions released. We
 recommend to point your application at the stable branch using Git. If you are
 not comfortable maintaining your own versions, you should upgrade to a supported
 version.
 
+Release schedule
+----------------
+
+We aim to release a version containing new features every six months. In the rare case where
+no release was made in one year, we will extend the support period for the previous release
+until the next release is made.
+
 npm Packages
 ------------
 
 Due to a constraint with npm, we are unable to use the 4th digit for security
 releases of [npm packages][] provided by Rails. This means that instead of the
-equivalent gem version `7.0.1.4`, the npm package will be versioned `7.0.1-4`.
+equivalent gem version `7.0.1.4`, the npm package will be versioned `7.0.104`.
 
 [npm packages]: https://www.npmjs.com/org/rails