Monthly releases
Monthly release overview
The monthly release is a semver versioned package containing changes from many successful deployments on GitLab.com. Users on GitLab.com, therefore, receive features and bug fixes earlier than users of self-managed installations.
The deployments and releases page details how the two processes work together.
Monthly release process
The monthly release timelines are concentrated around the release date.
Overview of the steps involved on the self-managed release process:
The end-to-end process consists on the following stages:
- First steps - Initial steps to setup the monthly release, including setting up the release schedule and the deployment cadence.
- GitLab.com deployments - From the start of the milestone up to one week before the release date, GitLab.com receives multiple deployments per day. For application changes to be considered in a self-managed release they need to be successfully deployed to GitLab.com.
- Candidate commit - One week before the release date a candidate commit is selected and broadcasted by release managers, the commit is usually the current commit running on GitLab.com. Pending GitLab.com availability, a different commit might be choosen, this means that the availability and stability of GitLab.com deployments will determine the cutoff date for inclusion in the release. This commit is announced in multiple Slack engineering channels, including #releases, #development, #backend, and #frontend.
- Release candidate - A test release candidate (RC) is created, along with a stable branch for the targeted semver version. The release candidate package is built, tested and deployed to the pre environment. A successful outcome indicates this package can be used as the final version. At this point release managers will announce the final commit to be included in the release.
- Tag - Release managers tag the final version of the release based on the release candidate. The release is built and deployed to the Release environment.
- Release - On the release day, the release packages are published.
Timelines
The only guaranteed date throughout the release cycle is the release date. On this date,
the self-managed release will be published together with the release announcement.
All other dates are a guideline only and cannot be considered a deadline when it comes to what will be included into any type of release. This includes the development month and the dates defined there as well as any promises given to customers. This is strictly because there are a lot of moving parts to be considered when preparing a release which includes working on highest priority and severity issues as well as security related issues.
If it is absolutely necessary to get a certain feature
ready for a specific version, merge the feature early in the development cycle.
Merges closer to the release date are absolutely not guaranteed to be included
in that specific monthly self-managed release.
How can I determine if my merge request will make it into the monthly release?
When we create release candidates, and when we create a new release package, the Release Tools project will add a label to the merge requests included.
For more information, refer to the Auto-deploy status command.
In the runup to the release date, release managers will also start announcing what commit will at the very least make it into the release. Such notifications are shared in Slack #releases channel and will look something like this (format is defined in the release-tools monthly template):
This is the candidate commit to be released on the release date. https://gitlab.com/gitlab-org/gitlab/commits/4033cb0ed66de77a4b5c1936e33de918edef558e
The last commit to make it into the release will have a message similar to this:
📣 Barring any show-stopping issues, this is the final commit to be released on the release date. https://gitlab.com/gitlab-org/gitlab/-/commits/13-1-stable-ee
Merge Requests that have been included in the monthly release will receive a label indicating inclusion.
Monthly release information dashboard
GitLab team members can view the internal Grafana dashboard “Release Information” for the following information:
- Upcoming monthly release version
- Upcoming monthly release date
- Current status of the upcoming monthly release
The metrics used to display this information are updated automatically throughout the monthly releases process.
Labels indicating inclusion in upcoming Self-managed release
As a merge request is included in monthly self-managed release candidates (RC), it will receive the
released::candidate label when the release candidate it is included in is deployed to
pre.gitlab.com. See “What is a release candidate and when are they created?”
for more information on release candidates. This label indicates that the MR will most
likely be included in the upcoming Self-managed release.
A merge request will receive the released::published label (which replaces the released::candidate label)
when included in a packaged release, such as 13.6.0 or 13.5.2, and deployed to
release.gitlab.net for both automated and manual testing. This label indicates that the
MR will be published with the Self-managed release.
Frequently Asked Questions
Who are the release managers for release X?
You can find this out by taking a look at the GitLab Release Managers schedule.
What is a release candidate and when are they created?
A release candidate (RC) is a GitLab package that includes the changes that will make it into the final self-managed release, except for the rare case where a change may need to be reverted. RCs are only created for the monthly self-managed release, not patch releases. The amount of RCs created per month will vary per release.
There is no fixed point in time where a release manager creates a release candidate. Instead, this is based entirely on how the release process has been going, what the state is of GitLab.com, etc.
Release candidates are created whenever possible, and as such there are no guarantees on creation timing. This will depend on factors such as:
- Any incidents on GitLab.com that are or have been going on in the run-up to the release.
- Any (critical) patch releases that require the attention of release managers.
- Any issues with our auto-deployment pipelines.
- Other release related work that may delay or prevent the creation of a release candidate until said work is dealt with.
In other words, if you want to know when a release candidate is created your best option is to join one of the following Slack channels:
Release candidates are deployed to pre.gitlab.com for both automated and
manual testing.
Will release managers create a release candidate earlier if I ask them to?
It is up to a release manager to decide when to create a release candidate, taking into account the state of deployments and GitLab.com.
Please do not message a release manager in private about release related questions or requests. Instead, post your request/question in the #releases channel.
When do I need to have my MR merged in order for it to be included into the monthly release?
The earlier in the monthly cycle your MR is merged, the higher the chances are for it to be included in that month’s release.
There is no guaranteed “cut-off”, “freeze” or any other date defined under which the MR will be included.
Availability, security and performance of GitLab.com is a pre-requisite for any monthly self-managed release. If GitLab.com is not experiencing any issues, MR’s merged as late as 2 days before the release date were included in the release. On the opposite side, when GitLab.com stability was lower, MR’s merged as early as one week before the release date of the month were not included.
In other words:
The quality and stability of what is delivered by everyone defines the final MR that will be included in the monthly release.
For more detailed information:
- Use the internal dashboard to verify the status of a merge request with respect to the monthly release.
- See self-managed release timelines.
- Refer to status of a merge request with respect to the monthly release documentation.
How can I get a high severity bug fix released?
Any high severity issue should start with an issue labeled with the appropriate bug and severity labels.
Depending on the bug details, follow one of the following processes:
- For high severity security bugs
- For high severity bugs affecting self-managed users. If the bug has been found close to the release date of the month please also alert the Release Managers in #releases.
- For high severity bugs affecting GitLab.com
- For high security bugs affecting security merge requests
7d8b05c3)
