Merge branch 'doc/mj-release-backports-policy' into 'master'

Expand patch release policy

See merge request gitlab-org/gitlab!18011

doc/policy/maintenance.md

@@ -30,21 +30,68 @@ The following table describes the version types and their release cadence:
 
 ## Patch releases
 
-Patch releases usually only include bug fixes and are only done for the current
-stable release. That said, in some cases, we may backport it to previous stable
+Our current policy is to support **only the current stable release** at any given time.
+
+Patch releases **only include bug fixes** for the current stable released version of
+GitLab.
+
+These two policies are in place because:
+
+1. GitLab has Community and Enterprise distributions, doubling the amount of work
+necessary to test/release the software.
+1. Backporting to more than one release creates a high development, quality assurance,
+and support cost.
+1. Supporting parallel version discourages incremental upgrades which over time accumulate in
+complexity and create upgrade challenges for all users. GitLab has a dedicated team ensuring that
+incremental upgrades (and installations) are as simple as possible.
+1. The number of changes created in the GitLab application is high, which contributes to backporting complexity to older releases. In number of cases, backporting has to go through the same
+review process a new change goes through.
+1. Ensuring that tests pass on older release is a considerable challenge in some cases, and as such is very time consuming.
+
+Including new features in patch releases is not possible as that would break [Semantic Versioning].
+Breaking [Semantic Versioning] has the following consequences for users that
+have to adhere to various internal requirements (e.g. org. compliance, verifying new features and similar):
+
+1. Inability to quickly upgrade to leverage bug fixes included in patch versions.
+1. Inability to quickly upgrade to leverage security fixes included in patch versions.
+1. Requirements consisting of extensive testing for not only stable GitLab release, but every patch version.
+
+In cases where a strategic user has a requirement to test a feature before it is
+officially released, we can offer to create a Release Candidate (RC) version that will
+include the specific feature. This should be needed only in extreme cases, and can be requested for consideration by raising an issue in [release/tasks] issue tracker.
+It is important to note that the Release Candidate will also contain other
+features and changes as it is not possible to easily isolate a specific feature (similar reasons as noted above). The Release Candidate will be no different than any code that is deployed to GitLab.com or is publicly accessible.
+
+### Backporting to older releases
+
+Backporting to more than one stable release is reserved for [security releases](#security-releases).
+In some cases however, we may need to backport *a bug fix* to more than one stable
 release, depending on the severity of the bug.
 
-For instance, if we release `10.1.1` with a fix for a severe bug introduced in
-`10.0.0`, we could backport the fix to a new `10.0.x` patch release.
+Decision on whether backporting a change will be performed is done at the discretion of the [current release managers][release-managers], similar to what is described in the [managing bugs] process, based on *all* of the following:
+
+1. Estimated [severity][severity-labels] of the bug: Highest possible impact to users based on the current definition of severity.
+
+1. Estimated [priority][priority-labels] of the bug: Immediate impact on all impacted users based on the above estimated severity.
+
+1. Potentially incurring data loss and/or security breach.
+
+1. Potentially affecting one or more strategic accounts due to a proven inability by the user to upgrade to the current stable version.
+
+If *all* of the above are satisfied, the backport releases can be created for
+the current stable stable release, and two previous monthly releases.
+For instance, if we release `11.2.1` with a fix for a severe bug introduced in
+`11.0.0`, we could backport the fix to a new `11.0.x`, and `11.1.x` patch release.
+
+To request backporting to more than one stable release for consideration, raise an issue in [release/tasks] issue tracker.
 
 ### Security releases
 
 Security releases are a special kind of patch release that only include security
 fixes and patches (see below).
 
-Our current policy is to support one stable release at any given time, but for
-medium-level security issues, we may backport security fixes to the previous two
-monthly releases.
+Our current policy is to backport security fixes to the previous two
+monthly releases in addition to the current stable release.
 
 For very serious security issues, there is
 [precedent](https://about.gitlab.com/blog/2016/05/02/cve-2016-4340-patches/)
@@ -91,3 +138,9 @@ Please see the table below for some examples:
 More information about the release procedures can be found in our
 [release documentation](https://gitlab.com/gitlab-org/release/docs). You may also want to read our
 [Responsible Disclosure Policy](https://about.gitlab.com/security/disclosure/).
+
+[release-managers]: https://about.gitlab.com/community/release-managers/
+[priority-definition]: ../development/contributing/issue_workflow.md#priority-labels
+[severity-labels]: ../development/contributing/issue_workflow.html#severity-labels
+[managing bugs]: https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md#managing-bugs
+[release/tasks]: https://gitlab.com/gitlab-org/release/tasks/issues