GitLab release and maintenance policy

The Release and Deploy team 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 and release pace for major, minor, patch releases. New releases are announced on the GitLab blog.

Our current policy is:

• Backporting bug fixes for only the current stable release at any given time - see patch releases below.
• Backporting security fixes to the previous two monthly releases in addition to the current stable release. In some circumstances (outlined in patch releases below) we may address a security vulnerability to the current stable release only or in the regular monthly release process, with no backports.

In rare cases, an exception may be granted to backport to more than the last two monthly releases. For the required process, see policy exceptions.

Versioning

GitLab uses Semantic Versioning for its releases: (Major).(Minor).(Patch).

For example, for GitLab version 18.3.2:

• 18 represents the major version. The major release was 18.0.0 but often referred to as 18.0.
• 3 represents the minor version. The minor release was 18.3.0 but often referred to as 18.3.
• 2 represents the patch number.

Any part of the version number can increment into multiple digits, for example, 18.3.11.

The following table describes the version types and their release cadence:

Maintained versions

The following GitLab release versions are currently maintained:

• 18.8 (bug and security fixes)
• 18.7 (security fixes)
• 18.6 (security fixes)

Upgrade recommendations

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 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.

Version-specific change documentation for Linux packages is available for:

• GitLab 17
• GitLab 16
• GitLab 15

Instructions are available for downloading the Linux package locally and manually installing it.

A step-by-step guide to upgrading the Linux package-bundled PostgreSQL is documented separately.

Upgrading major versions

Backward-incompatible changes and migrations are reserved for major versions. For more information, see Create a GitLab upgrade plan.

Patch releases

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:

1. GitLab has Community and Enterprise distributions, doubling the amount of work necessary to test/release the software.
2. Backporting to older releases creates a high development, quality assurance, and support cost.
3. 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.
4. The number of changes created in the GitLab application is high, which contributes to backporting complexity to older releases. In several cases, backporting has to go through the same review process a new change goes through.
5. Ensuring that tests pass on the older release is a considerable challenge in some cases, and as such is very time-consuming.

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):

1. Inability to quickly upgrade to leverage bug fixes included in patch versions.
2. Inability to quickly upgrade to leverage security fixes included in patch versions.
3. Requirements consisting of extensive testing for not only stable GitLab release, but every patch version.

For highly severe security issues, there is precedent to backport security fixes to even more previous GitLab release versions. For the required process, see policy exceptions.

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.

Policy exceptions

In exceptional circumstances, deviations from this maintenance policy may be necessary. This includes requests for backporting fixes to releases older than those covered by standard policy and deviations from the release principles Severity 3 and lower requests are automatically turned down.

To request a policy exception:

1. Raise an issue in the release/tasks issue tracker.
2. Document business justification including:
   • Severity and priority of the bug or feature.
   • Potential for data loss or security breach.
   • Customer impact and why upgrading to a maintained version is not feasible.
3. Obtain written approval from a sponsoring Director or VP.

Exceptions are granted at the discretion of the Release Managers as policy owners, subject to SLO commitments.

More information

You may also want to read our:

• Release documentation describing release procedures
• Deprecation guidelines in the development documentation.
• Responsible Disclosure Policy