Stable branches

Overview

Stable branches are the source of the GitLab release packages delivered to GitLab customers. They serve as a foundation for versioned releases, and it is fundamental that they remain reliable for any GitLab release process (monthly, patch or internal).

Principles

• At GitLab, it is everyone’s responsibility to keep stable branches green and reliable. Similar to master branch failures, addressing stable branch failures takes priority over everything else development-related.
• Stable branches receive bug fixes and security patches according to the maintenance policy.
• Stable branches can also receive upkeeping efforts & catch-up corrective improvements (performance improvements, documentation updates, spec fixes, etc).

Workflow

1. Stable branches are created when the initial release candidate of a monthly release is tagged.
2. After creation, stable branches are automatically propagated to security and dev repositories via repository mirroring.
3. Bug and security fixes are backported to stable branches based on the maintenance policy.
4. Changes backported to stable branches are automatically deployed to release environments to guarantee they’re compatible with the GitLab version.
5. Patch and internal releases are created from the content of stable branches.

Characteristics

• Stable branch permissions are based on the maintenance policy. Stable branches associated with the maintained versions are opened to GitLab maintainers for merging while older stable branches are limited to release managers.
• To account for security fixes and release environments, security repositories represent the SSOT for stable branches.
• Tests on stable branches are the same on canonical, security and dev repositories. With the exception of release environments that are only available on the GitLab security repository.