GitLab has strict policies governing version naming, as well as release pace for major, minor,
GitLab has strict policies governing version naming, as well as release pace for major, minor,
patch, and security releases. New releases are usually announced on the [GitLab blog](https://about.gitlab.com/releases/categories/releases/).
patch, and security releases. New releases are announced on the [GitLab blog](https://about.gitlab.com/releases/categories/releases/).
Our current policy is:
Our current policy is:
- Backporting bug fixes for **only the current stable release** at any given time. (See [patch releases](#patch-releases).)
- Backporting bug fixes for **only the current stable release** at any given time. (See [patch releases](#patch-releases).)
- Backporting **to the previous two monthly releases in addition to the current stable release**. (See [security releases](#security-releases).)
- Backporting security fixes **to the previous two monthly releases in addition to the current stable release**. (See [security releases](#security-releases).)
In rare cases, release managers may make an exception and backport to more than
the last two monthly releases. See [Backporting to older
releases](#backporting-to-older-releases) for more information.
## Versioning
## Versioning
...
@@ -177,7 +181,7 @@ accessible.
...
@@ -177,7 +181,7 @@ accessible.
### Backporting to older releases
### Backporting to older releases
Backporting to more than one stable release is reserved for [security releases](#security-releases).
Backporting to more than one stable release is normally reserved for [security releases](#security-releases).
In some cases, however, we may need to backport *a bug fix* to more than one stable
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.
release, depending on the severity of the bug.
...
@@ -188,16 +192,13 @@ based on *all* of the following:
...
@@ -188,16 +192,13 @@ based on *all* of the following:
1. Estimated [severity](../development/contributing/issue_workflow.md#severity-labels) of the bug:
1. Estimated [severity](../development/contributing/issue_workflow.md#severity-labels) of the bug:
Highest possible impact to users based on the current definition of severity.
Highest possible impact to users based on the current definition of severity.
1. Estimated [priority](../development/contributing/issue_workflow.md#priority-labels) of the bug:
1. Estimated [priority](../development/contributing/issue_workflow.md#priority-labels) of the bug:
Immediate impact on all impacted users based on the above estimated severity.
Immediate impact on all impacted users based on the above estimated severity.
1. Potentially incurring data loss and/or security breach.
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.
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
If *all* of the above are satisfied, the backport releases can be created for
the current stable release, and two previous monthly releases.
the current stable release, and two previous monthly releases. In rare cases a release manager may grant an exception to backport to more than two previous monthly releases.
For instance, if we release `11.2.1` with a fix for a severe bug introduced in
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.
`11.0.0`, we could backport the fix to a new `11.0.x`, and `11.1.x` patch release.
