diff options
Diffstat (limited to 'doc/policy/maintenance.md')
| -rw-r--r-- | doc/policy/maintenance.md | 28 |
1 files changed, 15 insertions, 13 deletions
diff --git a/doc/policy/maintenance.md b/doc/policy/maintenance.md index 217618c1771..d8b36fcaa6d 100644 --- a/doc/policy/maintenance.md +++ b/doc/policy/maintenance.md @@ -24,10 +24,10 @@ releases](#backporting-to-older-releases) for more information. GitLab uses [Semantic Versioning](https://semver.org/) for its releases: `(Major).(Minor).(Patch)`. -For example, for GitLab version 12.10.6: +For example, for GitLab version 13.10.6: -- `12` represents the major version. The major release was 12.0.0 but often referred to as 12.0. -- `10` represents the minor version. The minor release was 12.10.0 but often referred to as 12.10. +- `13` represents the major version. The major release was 13.0.0 but often referred to as 13.0. +- `10` represents the minor version. The minor release was 13.10.0 but often referred to as 13.10. - `6` represents the patch number. Any part of the version number can increment into multiple digits, for example, 13.10.11. @@ -55,13 +55,13 @@ one major version. For example, it is safe to: - Upgrade the *minor* version. For example: - - `12.7.5` -> `12.10.5` - - `11.3.4` -> `11.11.1` + - `13.7.5` -> `13.10.5` + - `12.3.4` -> `12.10.11` - Upgrade the *patch* version. For example: - - `12.0.4` -> `12.0.12` - - `11.11.1` -> `11.11.8` + - `13.0.4` -> `13.0.12` + - `12.10.1` -> `12.10.8` NOTE: Version specific changes in Omnibus GitLab Linux packages can be found in [the Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/update/README.html#version-specific-changes). @@ -119,7 +119,7 @@ release, depending on the severity of the bug. The decision on whether backporting a change will be performed is done at the discretion of the [current release managers](https://about.gitlab.com/community/release-managers/), similar to what is -described in the [managing bugs](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md#managing-bugs) process, +described in the [managing bugs](https://gitlab.com/gitlab-org/gitlab/-/blob/master/PROCESS.md#managing-bugs) process, based on *all* of the following: 1. Estimated [severity](../development/contributing/issue_workflow.md#severity-labels) of the bug: @@ -131,8 +131,8 @@ based on *all* of the following: If *all* of the above are satisfied, the backport releases can be created for 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 -`11.0.0`, we could backport the fix to a new `11.0.x`, and `11.1.x` patch release. +For instance, if we release `13.2.1` with a fix for a severe bug introduced in +`13.0.0`, we could backport the fix to a new `13.0.x`, and `13.1.x` patch release. To request backporting to more than one stable release for consideration, raise an issue in the [release/tasks](https://gitlab.com/gitlab-org/release/tasks/-/issues/new?issuable_template=Backporting-request) issue tracker. @@ -149,6 +149,8 @@ This decision is made on a case-by-case basis. ## More information -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/). +You may also want to read our: + +- [Release documentation](https://gitlab.com/gitlab-org/release/docs) describing release procedures +- [Deprecation guidelines](../development/deprecation_guidelines/index.md) +- [Responsible Disclosure Policy](https://about.gitlab.com/security/disclosure/) |