stage | group | info |
---|---|---|
Systems |
Distribution |
To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments |
The Delivery Group are the owners of the maintenance policy and must approve any requested updates. This follows our DRI model and is in place to ensure predictability for customers.
GitLab has strict policies governing version naming, as well as release pace for major, minor, patch releases. New releases are announced on the GitLab blog.
Our current policy is:
In rare cases, release managers may make an exception and backport to more than the last two monthly releases. See Backporting to older releases for more information.
GitLab uses Semantic Versioning for its releases:
(Major).(Minor).(Patch)
.
For example, for GitLab version 13.10.6:
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.
The following table describes the version types and their release cadence:
Version type | Description | Cadence |
---|---|---|
Major | For significant changes, or when any backward-incompatible changes are introduced to the public API. | Yearly. The next major release is GitLab 17.0, scheduled for May 16th, 2024. GitLab schedules major releases for May each year, by default. |
Minor | For when new backward-compatible functionality is introduced to the public API, a minor feature is introduced, or when a set of smaller features is rolled out. | Monthly. |
Patch | For backward-compatible bug fixes that fix incorrect behavior. See Patch releases. | As needed. |
We encourage everyone to run the latest stable release to ensure that you can upgrade to the most secure and feature-rich GitLab experience. To make sure you can run the most recent stable release, we are working hard to keep the update process simple and reliable.
If you are unable to follow our monthly release cycle, there are a couple of cases you must consider. Follow the upgrade paths guide to safely upgrade between versions.
NOTE: Version specific changes in Linux packages can be found in the Linux package documentation.
NOTE: Instructions are available for downloading the Linux package locally and manually installing it.
NOTE: A step-by-step guide to upgrading the Linux package-bundled PostgreSQL is documented separately.
Backward-incompatible changes and migrations are reserved for major versions. See the upgrade guide.
Patch releases include bug fixes for the current stable released version of GitLab and security fixes to the previous two monthly releases in addition to the current stable release.
These policies are in place because:
Including new features in a patch release 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 (for example, org. compliance, verifying new features, and similar):
For highly severe security issues, there is precedent to backport security fixes to even more previous GitLab release versions. This decision is made on a case-by-case basis.
In some circumstances, we may choose to address a vulnerability using the regular monthly release process by updating the active and current stable releases only, with no backports. Factors influencing this decision include the very low likelihood of exploitation, the low impact of the vulnerability, the complexity of security fixes and the eventual risk to stability. We always address high and critical security issues with a patch release.
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 includes the specific feature. This should be needed only in extreme cases and can be requested for consideration by raising an issue in the release/tasks issue tracker. It is important to note that the Release Candidate contains other features and changes as it is not possible to easily isolate a specific feature (similar reasons as noted above). The Release Candidate is no different than any code that is deployed to GitLab.com or is publicly accessible.
Backporting to more than one stable release is usually reserved for security fixes. 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.
The decision on whether backporting a change is performed is done at the discretion of the current release managers, 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 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.
Note that severity 3 and lower requests are automatically turned down.
To request backporting to more than one stable release for consideration, raise an issue in the release/tasks issue tracker.
You may also want to read our:
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。