Skip to content

Breaking Change Exception Request - Drop Amazon Linux 2 packages

Breaking Change Exception Request

Executive summary

The GitLab Linux Package is build for several OSes, including AL2 (Amazon Linux 2). AL2 will be EOL in June 2026 and we want to announce it's deprecation and removal in gitlab-org/omnibus-gitlab#8845.

Our Linux Package support policy states that drop package builds once a vendor stop supporting the EOL, with at least a 6 month announcement timeframe.

Since AL2 is becoming harder and harder to support, we want to drop it in GitLab 19.1 (June 2026) and announce it's removal not later then 18.7

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.
    1. The deprecation can't be migrated by us, as we don't have control over the infrastructure pieces GitLab is deployed to.
  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.
    1. AL2 should be low (<1% of all installs). TO BE CONFIRMED.
  3. The breaking change is being implemented due to a significant security risk- Severity 1 or 2.
    1. No. But AL2 won't receive any (security) updates post this date.

Impact assessment

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

Can we get the same outcome without a breaking change?

No

When do you want to make the breaking change?

19.1

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

No alternaitve. Customers must migrate to Amazon Linux 2023 or another OS.

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

Amazon provides migration documentation: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.migration-al.generic.from-al2.html

Rollout & Communication plan

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

We dropped support for several OSes before. Because this needs proper planning on the customer site, we decided to announce OS removals 6 months in advance instead of the usual 3 months.

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

Impact can't be phased or lessened.

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 Clemens Beck