docs.gitlab.com release 17.11 (April, 2025)
Tasks for all releases
Documentation for handling the docs release is available.
Terminology
The following terms are used throughout this document:
-
Stable branch: This is the branch that matches the GitLab version being released. For example,
for GitLab 17.2, the stable branch is
17.2.
On Monday the week of the release
-
Ensure required tools are installed and up-to-date. In the root path of the docs-gitlab-comrepository:-
Update your local clone:
make update -
Install and update all project dependencies:
make setup -
Ensure you're authenticated with
glab:$ glab auth status gitlab.com ✓ Logged in to gitlab.com as <username> (<$HOME>/.config/glab-cli/config.yml) ✓ Git operations for gitlab.com configured to use ssh protocol. ✓ API calls for gitlab.com are made over https protocol. ✓ REST API Endpoint: https://gitlab.com/api/v4/ ✓ GraphQL Endpoint: https://gitlab.com/api/graphql/ ✓ Token: **************************
-
-
Cross-link to the main MR for the release post: gitlab-com/www-gitlab-com!138818 (merged) -
In this issue, create separate threads for the retrospective, and add items as they appear: ## :+1: What went well this release? ## :-1: What didn't go well this release? ## :chart_with_upwards_trend: What can we improve going forward? -
Add the version to be removed from the version dropdown list to the docs archives ( gitlab-docs-archives) repository:make create-archive-branchDo NOT create a merge request. After a couple of minutes, the version will be deployed. You can visit https://archives.docs.gitlab.com/17.9 and verify.
On the Thursday of the release, or the day after
After the release post is live, or the day after:
-
In the root path of the docs-gitlab-comrepository, use thecreate-stable-branchMake target to create the stable branch:make create-stable-branch VERSION=17.11- You can track the progress of the stable branch pipeline from the pipelines list.
- When the stable branch pipeline completes, the new version will be available at https://docs.gitlab.com/17.11. Verify that the new release is functional, then proceed to the next step.
-
In the root path of the docs-gitlab-comrepository, use thecreate-release-merge-requestMake target to create the release merge request. This merge request updates the version dropdown list for all online versions:make create-release-merge-request VERSION=17.11-
Verify that the merge request: - Has the release label.
- Includes only the following in the Changes tab:
.gitlab/ci/docker-images.gitlab-ci.ymlcontent/versions.json
-
-
Ask in Slack in #tw-teamfor someone to review and merge the release merge request for you. -
After the deployment completes, open docs.gitlab.comin a browser. Confirm both the latest version and the correct pre-release version are listed in the version dropdown list. Note that it may take up to 5 minutes for the deployed changes to appear on the website due to caching. -
Check the version dropdown list to ensure all versions of the docs are visible and their version dropdown lists have the expected versions. - Versions hosted on
docs.gitlab.comshould show the same version options as the pre-release site. - Versions hosted on
archives.docs.gitlab.comshould only show their own version and a link back to the archives page.- This applies to GitLab 15.6 and later. Earlier versions might have broken links in the version dropdown list. This will eventually be resolved as the earlier versions are phased out.
- Versions hosted on
-
Share the following message in the #tw-teamchannel::mega: The docs <version> release is complete. If you have any feedback about this release, add it to the retro thread in <this issue>.
Post-deployment checklist
After the docs release is complete:
-
Create a release issue for the next release, and assign it to the TW who completed the release post structural check for the current milestone. -
Major releases only. Update OutdatedVersions.ymlwith the latest outdated version. -
Improve this checklist.