Skip to content

Breaking Change Exception Request - Drop Ubuntu 20.04 Linux packages

Breaking Change Exception Request

Executive summary

gitlab-org/omnibus-gitlab#8915 want to drop support for Ubuntu 20.04 Linux packages in 18.9. Ubuntu 20.04 is not supported anymore my the vendor since May 2025. Customers can get extended support by purchasing Ubuntu Pro, but if not these systems do not receive security updates for the systems packages.

For our Omnibus Linux package we only want to build supported and maintained distros to reduce build costs and maintenance burden.

Customers still on Ubuntu 20.04 will need to upgrade to Ubuntu 22.04 to keep receiving upgrades.

Does your breaking change meet one of these three criteria?

  1. The impact of the breaking change has been fully mitigated via an automated migration that requires no action from the customer.
    • Not possible - Users will have to upgrade their OS manually.
  2. The breaking change will have negligible customer impact as measured by actual product usage tracking across Self-Managed, GitLab.com, and Dedicated. For instance if it impacts less than 1% of the GitLab customer base.
    • This impacts Self-Managed only - see below.
  3. The breaking change is being implemented due to a significant security risk- Severity 1 or 2.
    • No direct security impact on the GitLab instance, but the underlying systems do not receive security updates anymore.

Impact assessment

How many users and customers are impacted? What Tier/ARR of customer?

Currently, 6% of self-managed customer ARR is deploying Ubuntu 20.04 with a declining trend. At 18.9 release, 5% of customer ARR will be deploying this OS.

Screenshot 2025-11-03 at 16.46.38.png

Can we get the same outcome without a breaking change?

No

When do you want to make the breaking change?

GitLab 18.9

What is the alternative for customers to do the same job the change will break?

No alternative - Timing can be discussed but all users will need to migrate manually.

How difficult is it for customers to migrate to the alternative? Is there a migration plan?

Users will have to upgrade to Ubuntu 22 to receive security updates for the system and future GitLab versions.

Canonical offers a migration/upgrade guide: https://documentation.ubuntu.com/server/how-to/software/upgrade-your-release/

Rollout & Communication plan

Have we handled similar breaking changes in the past? What can we learn from the success or failure of those methods?

In the past we followed upstream end of life dates for most of our packages. Ubuntu 20 is EoL since May 2025, but we kept the packages for now to give FIPS users more time to migrate.

Are you employing any strategies to lessen the customer or support impact?

No options to reduce impact.

Internal Communication

  • Engineering, Product, Security, Customer Success, and Sales: What questions do you anticipate they will have? What is it important that they know?
  • Support: What guidance will the support team need to handle customer tickets related to this change?
    • Once you receive approval to proceed with the breaking change you should create a Support Preparedness issue with instructions on how to handle customer queries and concerns.

Customer Communication

Approval Process

  • Tag in the appropriate Product Director and Engineering Director for your product area. They may ask for further clarifications.
    • Approved by Product Director: < Add Name >
    • Approved by Engineering Director: < Add Name >
  • Once you have approval from both Directors, add the label "Breaking Change: Awaiting VP Approval" and remove the prior label.
  • This will be added to the agenda for Prod + Eng Weekly Strategy meeting to be reviewed. If it is granted VP approval they will add the "Breaking Change: VP Approved" label.
    • Approved by Product VP: < Add Name >
    • Approved by Engineering VP: < Add Name >
  • Seek approval on any customer comms from the Corporate Communications and Customer Success teams
Edited by Martin Brümmer