Upgrade Path
-
Current upgrade path in the documentation
-
Optional: If you are upgrading from an older major version not listed in the docs: Select the upper right corner version field, and chose older versions to get access to earlier versions in the upgrade path.
- Example, taken on 2024-08-13
- Example, taken on 2024-08-13
-
Optional alternative: follow the interactive suggested path planner in Upgrade Path
Requirements
- It is important to install specific versions during the upgrade path. There is no “catch all one time” upgrade procedure.
- Ensure that GitLab and GitLab Runner remain compatible in their versions after upgrades.
Recommendations
- Review breaking changes and deprecations before upgrades, so you can estimate potential missing features or configuration issues during the upgrade cycles.
- Upgrades also include database migrations, and might take a while. Plan with maintenance offline time if the migrations cannot be run in the background.
- It is advised to create a backup before upgrading.
- Check if the Linux distribution is still supported by the latest GitLab package version. If not, you need to plan with a distribution upgrade in the “middle” of the upgrade path, to gain access to newer GitLab packages again.
- For example, GitLab 14.6.1 on Ubuntu 18.04 LTS to GitLab 17.2.1 on Ubuntu 24.04 LTS.
- Document shorter upgrade cycles to keep future installations secure and stable, and reduce upgrade maintenance.
- Review the GitLab release and maintenance policy
- You can also enable unattended upgrades to automatically install security, patch and feature releases. (this depends on the used OS/distribution and eventually, company policies).