# Breaking Change Exception Request ## Executive summary The dependency proxy for Maven packages was a proof-of-concept for the future development of virtual repositories. Now that we have a Maven virtual repository, we'd like to clean up the code base by deprecating (now) and removing (20.0) the feature. We've already been recommending this path to customers for months. ### Does your breaking change meet one of these three criteria? 1. 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. Yes - there will be negligible customer impact. ## Impact assessment ### How many users and customers are impacted? What Tier/ARR of customer? We don't have user counts, but looking at the data, we can see almost no files are being pulled via this feature. {width="900" height="594"} Compare that to the current usage of the Maven virtual repository {width="900" height="396"} ### Can we get the same outcome without a breaking change? No, it's confusing to users and Support bears the burden of clarifying which product should be used. ### When do you want to make the breaking change? 20.0 ### What is the alternative for customers to do the same job, the change will break? Use the Maven virtual registry ### How difficult is it for customers to migrate to the alternative? Is there a migration plan? No migration plan as usage is negligible ### Does this breaking change interact with [other proposed or approved breaking changes?](https://gitlab.com/gitlab-com/Product/-/boards/9741901) No ## Rollout & Communication plan ### Have we handled similar breaking changes in the past? What can we learn from the success or failure of those methods? N/A ### Are you employing any strategies to lessen the customer or support impact? Usage is negligible. We will communicate via the standard deprecation/breaking change notice process. Additionally, we will identify impacted customers on GitLab.com and message them directly. ### Internal Communication - Engineering, Product, Security, Customer Success, and Sales: This is a low-impact change. The dependency proxy for Maven packages is being replaced by the Maven virtual repository, which is already available and recommended. No action is required from internal teams beyond awareness. - Support: Customers should be directed to use the Maven virtual registry as the replacement. A Support Preparedness issue will be created upon approval with detailed guidance for handling any customer queries. ### Customer Communication What form will this take? We will publish a deprecation notice following the standard deprecation/breaking change notice process. For GitLab.com, we will identify customers with active usage and message them directly to ensure they are aware of the change and the migration path to the Maven virtual registry. Can you inform the impacted customers directly rather than sharing a generic message to those who may not need to take action? Yes. We will identify customers on GitLab.com with active usage of the dependency proxy for Maven packages and reach out to them directly. If you are sharing communications with customers, the plan and written copy must be approved by the **Corporate Communications** and **Customer Success** teams. See the process [documented here.](https://internal.gitlab.com/handbook/legal-and-corporate-affairs/legal-and-compliance/comms-approval-process/) ## Approval Process You should ensure you have received approval and communicated your breaking change at least **three months** in advance of the implementation date. It is recommended that you open this request at least **six months** in advance to have time for the approval process. It is the requestor's responsibility to drive the approval process forward and ensure it is completed in the recommended timeframe. - [x] Tag in the appropriate Product Director and Engineering Director for your product area. They may ask for further clarifications. - [x] Approved by **Product Director or GPM**: @derekferguson - [x] Approved by **Engineering Director**: @m_gill - [x] Once you have approval from both Product GPM or Director & Engineering Director, add the label "Breaking Change: Awaiting Support Approval" and remove the prior label. - [x] Share this issue in the [#support_leadership](https://gitlab.enterprise.slack.com/archives/C01F9S37AKT) slack channel and ask for a review from the support perspective. Once you get signoff from 1 Support Senior Leader, add the label "Breaking Change: Awaiting VP Approval" and remove the prior label. - [x] Approved by **Support Stable Counterpart (If Applicable)**: @kategrechishkina SSC for for both the `package_registry` and `container_registry` - [x] Approved by **Support Senior Manager or Director**: @weimeng-gtlb - [x] Tag in the appropriate Product and Engineering VPs or Senior Directors for your product area. They may ask for further clarifications. - [x] Approved by **Product VP or Senior Director**: \< Add Name \> - [ ] Approved by **Engineering VP or Senior Director**: \< Add Name \> - [x] Once you have approval from both the Engineering & Product VP or Senior Director, add the "Breaking Change: VP Approved" label. **Please keep this issue open** until the breaking change has been implemented. This ensures all breaking changes are visible to leadership on [this board.](https://gitlab.com/gitlab-com/Product/-/boards/9741901) - [x] Once you have VP approval, create a [public deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Deprecations.md) that will serve as a source of truth for customers in regards to the change. - [x] Ensure the change is added to the deprecations docs page by following [this guidance.](https://docs.gitlab.com/development/deprecation_guidelines/#update-the-deprecations-and-removals-documentation) - [x] Seek approval on any customer comms from the **Corporate Communications** and **Customer Success** teams