Proposal: Rebrand patch releases for releases that include bug and security fixes
Context
To comply with the Maintenance Policy, GitLab has three release types:
- Monthly releases to release new GitLab versions including features and bug fixes.
- Patch releases to release bug fixes, limited to the current version.
- Security releases to release security fixes to the last three versions (current version and two previous versions).
During the past quarters, Delivery has worked to adapt the GitLab release processes to address customers' needs by combining and scheduling patch and security releases (see Sources for details). As a result, since 16.7 GitLab has performed only two release types: Monthly releases as expected, and Security releases, as a combined and scheduled release that includes bug and security fixes. This model has been extremely beneficial:
- Fixes are delivered to GitLab customers sooner guaranteeing the bug and security SLAs are always met.
- Frequent releases remove the blocking nature of security releases from developers: Engineers don't have to wait one month for the next security release
- Combined releases pave the way to extend the Maintenance Policy &971
- Backport requests targeting specific versions are automatically addressed, removing toil from release managers.
Because of the above, combined and scheduled releases are a release practice Delivery plan to officially adopt on FY25Q1. This issue aims to determine how to refer to the new release type.
State of the art
GitLab Releases
- Patch and security releases have been combined and scheduled to adapt to customer needs: Since 16.7, security releases have included a good number of bug fixes (details 1, 2).
-
- The patch/security releases are scheduled based on the Release SLO.
- The patch/security release is based on the self-serve mindset, it releases bugs and security fixes that are ready at any given time.
- Based on the pending fixes, the patch/security release might only include bug fixes or only include security fixes.
- Patch/security releases that are required and not scheduled will be considered unplanned and involve an RCA (work to be done on &1193 (closed))
- Because of backport requests, there could be a scenario where a patch release for a single version might be required.
- No exclusive patch release has been created since 2023-11-14.
Release practices from other notable companies
Company | Release name | Details |
---|---|---|
Grafana | Releases | It is a single type, the releases include features and bug fixes (bug fixes can be security fixes) |
Atlassian | Releases | It is a single type, all releases include bug and security fixes |
Jenkins | Releases | It is a single type, all releases include bug and security fixes |
Microsoft | Monthly security release | Multiple release types. The monthly security release type includes bug and security fixes |
RedHat | Major release, minor release | Multiple release types. All releases include bug and security fixes |
Kubernetes | Patch release | Monthly release including bug and security fixes |
Proposal: Rebrand patch releases for releases that include bug and security fixes.
The term "patch release" can be repurposed for releases that include bug and security fixes. The broad term represents the current GitLab release practices, and simplifies the GitLab release model into two categories:
- Monthly release - A
major.minor
GitLab release including features and bug fixes. - Patch release - A
major.minor.patch
release including bug and security fixes.
Pros
- The term 'patch release' is broad enough to represent a release that includes bug and security fixes.
- The term 'patch release' matches the semantic versioning practices which are aligned with the GitLab release principles
- The term 'patch release' is a familiar term for GitLab customers and internal users, which would be helpful with the transition
- The term 'patch release' follows world-wide practices
Cons
- Learning curve. At the beginning, it could confuse GitLab users since the term has been related to a release with bug fixes only. Continuous reinforcement will be required to minimize the confusion until the term has been fully adopted
- Release tooling updates. The Delivery relies on the distinction of patch and security release, tooling adjustments will be necessary.
Important items to highlight:
- GitLab maintenance policy stays as-is. Bug fixes are limited to the current version, and security fixes will apply to the last three versions.
- The update is a terminology change, not a process one. The term patch releases won't alter the patch or security release process for Engineers, AppSec or release managers.
- There will be two types of patch releases:
- Planned - All patch releases are scheduled by default based on the release SLO
- Unplanned - A reactive release if it is deemed necessary.
- Switching to patch releases is an ample change to be done iteratively:
- Terminology and tooling need to be adjusted.
- Education for GitLab team members and GitLab customers
- Information needs to be broadcasted repeatedly to multiple GitLab departments
Other options considered
Option A - Patch (security) release
Use the term "Patch security release" to refer to releases that include bug and security fixes, and the term "patch release" for releases that only include bug fixes.
Pros:
- Simple enough and hard to misunderstand
- Conveys that the release includes bug and security fixes
- It is a familiar term for GitLab customers and GitLab internal users
Cons
- Tooling adjustments required
Option B - Patch release
Use the term "Patch release" to refer to releases that include bug and security fixes.
Pros
- Broad enough to convey that the release includes bug and security fixes
- It is a familiar term for GitLab customers and internal users.
Cons
- It could confuse GitLab stakeholders since the patch release term has been related to a release with bug fixes only.
- Tooling adjustments required
Option C - Security release
Use the term "Security release" to refer to releases that include bug and security fixes.
Pros
- It is a familiar term for GitLab customers and GitLab internal users
Cons
- The name implies the release only includes security fixes.
- The release content will not match the name if only bug fixes are included.
- Tooling adjustments required
Option D - Planned release
Use the term "Planned release" to refer to releases that include bug and security fixes.
Pros
- It conveys the release cadence
Cons
- It is an unfamiliar term for customers and internal users.
- It will require a learning curve for GitLab stakeholders.
- It doesn't reflect the release could include bug and security fixes.
- Tooling adjustments required
Sources
Click to expand
- Update Delivery tools and processes to support ... (&1039 - closed)
- Automate combining bug fixes and security fixes... (&1073 - closed)
- Reduce Security release preparation to less tha... (&1061 - closed)
- Testing two security releases during the 16.7 m... (&1171 - closed)
- Testing two security releases during the 16.8 m... (&1190 - closed)
- Patch and security releases during the last quarters
List of patch/security releases of the last quarters
- https://about.gitlab.com/releases/2024/02/07/security-release-gitlab-16-8-2-released/
- https://about.gitlab.com/releases/2024/01/25/critical-security-release-gitlab-16-8-1-released/
- https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/
- https://about.gitlab.com/releases/2023/12/13/security-release-gitlab-16-6-2-released/
- https://about.gitlab.com/releases/2023/11/30/security-release-gitlab-16-6-1-released/
- https://about.gitlab.com/releases/2023/09/28/security-release-gitlab-16-4-1-released/
- The last patch release exclusive for a single version was on 2023-11-14,