Skip to content

Commit 06d4448

Browse files
committed
Change location of the maintenance policy document. Add version support information. [CI skip]
1 parent 565a2d7 commit 06d4448

File tree

2 files changed

+84
-33
lines changed

2 files changed

+84
-33
lines changed

MAINTENANCE.md

+1-33
Original file line numberDiff line numberDiff line change
@@ -1,35 +1,3 @@
11
# GitLab Maintenance Policy
22

3-
GitLab follows the [Semantic Versioning](http://semver.org/) for its releases:
4-
`(Major).(Minor).(Patch)` in a [pragmatic way].
5-
6-
- **Major version**: Whenever there is something significant or any backwards
7-
incompatible changes are introduced to the public API.
8-
- **Minor version**: When new, backwards compatible functionality is introduced
9-
to the public API or a minor feature is introduced, or when a set of smaller
10-
features is rolled out.
11-
- **Patch number**: When backwards compatible bug fixes are introduced that fix
12-
incorrect behavior.
13-
14-
The current stable release will receive security patches and bug fixes
15-
(eg. `8.9.0` -> `8.9.1`). Feature releases will mark the next supported stable
16-
release where the minor version is increased numerically by increments of one
17-
(eg. `8.9 -> 8.10`).
18-
19-
Our current policy is to support one stable release at any given time, but for
20-
medium-level security issues, we may consider [backporting to the previous two
21-
monthly releases][rel-sec].
22-
23-
We encourage everyone to run the latest stable release to ensure that you can
24-
easily upgrade to the most secure and feature-rich GitLab experience. In order
25-
to make sure you can easily run the most recent stable release, we are working
26-
hard to keep the update process simple and reliable.
27-
28-
More information about the release procedures can be found in our
29-
[release-tools documentation][rel]. You may also want to read our
30-
[Responsible Disclosure Policy][disclosure].
31-
32-
[rel-sec]: https://gitlab.com/gitlab-org/release-tools/blob/master/doc/security.md#backporting
33-
[rel]: https://gitlab.com/gitlab-org/release-tools/blob/master/doc/
34-
[disclosure]: https://about.gitlab.com/disclosure/
35-
[pragmatic way]: https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e
3+
See [doc/policy/maintenance.md](doc/policy/maintenance.md)

doc/policy/maintenance.md

+83
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,83 @@
1+
# GitLab Maintenance Policy
2+
3+
## Versioning
4+
5+
GitLab follows the [Semantic Versioning](http://semver.org/) for its releases:
6+
`(Major).(Minor).(Patch)` in a [pragmatic way].
7+
8+
- **Major version**: Whenever there is something significant or any backwards
9+
incompatible changes are introduced to the public API.
10+
- **Minor version**: When new, backwards compatible functionality is introduced
11+
to the public API or a minor feature is introduced, or when a set of smaller
12+
features is rolled out.
13+
- **Patch number**: When backwards compatible bug fixes are introduced that fix
14+
incorrect behavior.
15+
16+
For example, for GitLab version 10.5.7:
17+
18+
* `10` represents major version
19+
* `5` represents minor version
20+
* `7` represents patch number
21+
22+
## Security releases
23+
24+
The current stable release will receive security patches and bug fixes
25+
(eg. `8.9.0` -> `8.9.1`).
26+
27+
Feature releases will mark the next supported stable
28+
release where the minor version is increased numerically by increments of one
29+
(eg. `8.9 -> 8.10`).
30+
31+
Our current policy is to support one stable release at any given time.
32+
For medium-level security issues, we may consider backporting to the previous two
33+
monthly releases.
34+
35+
For very serious security issues, there is [precedent](https://about.gitlab.com/2016/05/02/cve-2016-4340-patches/)
36+
to backport security fixes to even more monthly releases of GitLab. This decision
37+
is made on a case-by-case basis.
38+
39+
## Version support
40+
41+
We encourage everyone to run the latest stable release to ensure that you can
42+
easily upgrade to the most secure and feature-rich GitLab experience. In order
43+
to make sure you can easily run the most recent stable release, we are working
44+
hard to keep the update process simple and reliable.
45+
46+
If you are unable to follow our monthly release cycle, there are a couple of
47+
cases you need to consider.
48+
49+
It is considered safe to jump between patch versions and minor versions within
50+
one major version. For example, it is safe to:
51+
52+
* Upgrade the patch version:
53+
* `8.9.0` -> `8.9.7`
54+
* `8.9.0` -> `8.9.1`
55+
* `8.9.2` -> `8.9.6`
56+
* Upgrade the minor version:
57+
* `8.9.4` -> `8.12.3`
58+
* `9.2.3` -> `9.5.5`
59+
60+
Upgrading the major version requires more attention.
61+
We cannot guarantee that upgrading between major versions will be seamless. As previously mentioned, major versions are reserved for backwards incompatible changes.
62+
63+
We recommend that you first upgrade to the latest available minor version within
64+
your major version. By doing this, you can address any deprecation messages
65+
that could possibly change behaviour in the next major release.
66+
67+
Please see the table below for some examples:
68+
69+
| Latest stable version | Your version | Recommended upgrade path | Note |
70+
| -------------- | ------------ | ------------------------ | ---------------- |
71+
| 9.4.5 | 8.13.4 | `8.13.4` -> `8.17.7` -> `9.4.5` | `8.17.7` is the last version in version `8` |
72+
| 10.1.4 | 8.13.4 | `8.13.4` -> `8.17.7` -> `9.5.8` -> `10.1.4` | `8.17.7` is the last version in version `8`, `9.5.8` is the last version in version `9` |
73+
|
74+
75+
76+
More information about the release procedures can be found in our
77+
[release-tools documentation][rel]. You may also want to read our
78+
[Responsible Disclosure Policy][disclosure].
79+
80+
81+
[rel]: https://gitlab.com/gitlab-org/release-tools/blob/master/doc/
82+
[disclosure]: https://about.gitlab.com/disclosure/
83+
[pragmatic way]: https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e

0 commit comments

Comments
 (0)