@@ -30,21 +30,68 @@ The following table describes the version types and their release cadence:
...
@@ -30,21 +30,68 @@ The following table describes the version types and their release cadence:
## Patch releases
## Patch releases
Patch releases usually only include bug fixes and are only done for the current
Our current policy is to support **only the current stable release** at any given time.
stable release. That said, in some cases, we may backport it to previous stable
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.
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
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:
`10.0.0`, we could backport the fix to a new `10.0.x` patch release.
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
Security releases are a special kind of patch release that only include security
Security releases are a special kind of patch release that only include security
fixes and patches (see below).
fixes and patches (see below).
Our current policy is to support one stable release at any given time, but for
Our current policy is to backport security fixes to the previous two
medium-level security issues, we may backport security fixes to the previous two
monthly releases in addition to the current stable release.
