Deprecate: Dependency proxy for packages (Maven)

Deprecation Summary

We propose to deprecate the Dependency Proxy for packages feature. This feature allowed users to define a single upstream repository to proxy and cache packages from. However, the feature has been hampered by persistent performance problems and key missing functionality, particularly the inability to configure multiple upstream repositories. Users should migrate to the Maven Virtual Registry, which provides a more robust solution with support for multiple upstream repositories.

While we're marking this for deprecation, we recognize GitLab's commitment to avoiding breaking changes and minimizing disruption to user workflows. The primary goal is to guide users toward the improved Maven Virtual Registry solution while maintaining the existing functionality for a reasonable transition period. This deprecation notice will help set proper expectations for users and prevent new adoption of a feature we plan to eventually sunset.

Documentation

  • Deprecation notice: TBD
  • Migration guidelines: TBD

Product Usage

The Dependency Proxy for packages has shown declining usage over the past year.

Breaking Change?

Does this deprecation contain a breaking change? No

Affected Customers

Who is affected by this deprecation: GitLab.com users, Self-managed users, or Dedicated users? (choose all that apply)

  • GitLab.com
  • Self-managed
  • Dedicated

What pricing tiers are impacted?

  • GitLab Free
  • GitLab Premium
  • GitLab Ultimate

[ ] Internal note outlining details of customer impact has been created

Deprecation Milestone

This deprecation will be announced in milestone: 18.2

Planned Removal Milestone

The feature / functionality will be removed in milestone: 20.0

However, we're not rushing the removal given GitLab's commitment to avoiding breaking changes. We'll use the deprecation period to gather usage data, ensure adequate migration paths exist, and potentially extend the timeline if necessary to give users sufficient time to migrate their workflows. The primary goal is to establish the Maven Virtual Registry as the recommended approach while supporting a smooth transition.

Checklists

Timeline

Rollout Plan

  • DRI Engineers: @package-registry-engineers

  • DRI Engineering Manager: @package-registry-em

  • Describe rollout plans on GitLab.com

    • Link to a feature flag rollout issue that covers:
      • Expected release date on GitLab.com and GitLab version
      • Rollout timelines, such as a percentage rollout on GitLab.com
      • Creation of any clean-up issues, such as code removal

  • Determine how to migrate users still using the existing functionality

  • Document ways to migrate with the tooling available

  • Automate any users who have not yet migrated, but ensure it's a two-way door decision

Communication Plan

  • DRI Product Manager: @package-registry-pm

Internal Communication Plan

  • Create an internal note in the comment thread of this issue with a comprehensive narrative of customer impacts, with the intended audience of internal stakeholders who directly interact with customers.
  • Internal announcement plan (timeline for notifications, audience, channels, etc)
  • Support and enablement plan
    • Support readiness: Document how the support team should handle tickets related to this deprecation / breaking change.
    • Customer Success readiness: Ensure the CS team knows how to bring questions or concerns from clients to the right internal team members.

External Communication Plan

  • Customer announcement plan (timeline for notifications, audience, channels, etc)
  • Ensure you have approvals from legal and corp comms for any communication being sent directly to customers.
  • As soon as possible, but no later than the third milestone preceding the major release, ensure that the following are complete:
    • A deprecation announcement entry has been created so the deprecation will appear in release posts and on the general deprecation page.
    • Documentation has been updated to mark the feature as deprecated.
  • On the major milestone:
    • The deprecated item has been removed.
    • If the removal of the deprecated item is a breaking change, the merge request is labeled breaking change.
    • Document the migration plan for users, clearly outlining the actions they need to take to mitigate the impact of the breaking change.
      • Migration guide for Maven Virtual Registry

Development

  • DRI Engineers: @package-registry-engineers

  • DRI Engineering Manager: @package-registry-em

  • Measure usage of the impacted product feature

    • Evaluate metrics across GitLab.com, Self-Managed, Dedicated
    • [Dashboard link to be added]
    • Collect data on actual user dependency patterns to inform migration strategies

  • Create tooling for customers to manually migrate their data or workflows

    • Develop migration guide with detailed steps for converting dependency proxy configurations to Maven Virtual Registry configurations
    • Consider creating a migration assistant or visualization tool to help users understand the changes

  • Build mechanism for users to manually enable the breaking change ahead of time

    • Add option in UI to preview the Maven Virtual Registry behavior while maintaining the existing functionality

  • Prioritize education and guidance over forced migration

    • Implement clear UI indicators about the deprecation without disrupting existing workflows
    • Create awareness through UI hints and documentation before implementing any technical changes

  • Develop gradual rollout plan that prioritizes user experience

    • [Feature flag rollout issue to be linked]

  • Dogfood the changes on GitLab.com or a Self-Managed test instance

    • Thoroughly test migration process internally with complex dependency scenarios

Approvals

  • Product Manager @trizzi
  • Engineering Manager @crystalpoole
  • Senior Engineering Manager / Director
  • Group / Director of Product Management
  • Product / Eng Leaders in the CPO or CTO organizations, as applicable (optional - depends on scope of change)

Labels

  • This issue is labeled deprecation, and with the relevant ~devops::, ~group::, and ~Category: labels.
  • This issue is labeled breaking change as the removal of the deprecated item will be a breaking change.
Edited by Tim Rizzi