Skip to content

Breaking change exception: Remove bin_path and use_bundled_binaries config options

Breaking Change Exception Request

Executive summary

Starting 18.3, bin_path and use_bundled_binaries config options have been deprecated and are no-op in Gitaly. In version 19.0, we plan to fully remove these fields.

The impact of this removal is benign, as these configurations no longer affect functionality.

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.

    There is no action needed. After the fields are removed, if a customer continues to use them, they will receive an error.

  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.

    No

  3. The breaking change is being implemented due to a significant security risk- Severity 1 or 2.

    No

Impact assessment

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

We don't have telemetry indicating how many users are using these fields.

Can we get the same outcome without a breaking change?

No

When do you want to make the breaking change?

19.0

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

There are no alternatives.

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

NA

Rollout & Communication plan

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

Are you employing any strategies to lessen the customer or support 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

What form will this take?

Can you inform the impacted customers directly rather than sharing a generic message to those who may not need to take action?

If you are sharing communications with customers, the plan and written copy must be approved by the Corporate Communications team and the Customer Success Team.

Approval Process

  • Tag in the appropriate Product Director and Engineering Director for your product area. They may ask for further clarifications.
  • 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 Divya Rani