@trizzi Do you have any data around how much this is used? Since this is technically still experimental, we shouldn't need to worry about it being a breaking change, but I'm still curious about usage and whether we should try to have any in-product communication pushing people to the virtual registry.

@trizzi Even though this is just the deprecation notice, there is the intent indicated in the notice to remove support for the feature in a future milestone. This needs to be treated as a breaking change, especially since the alternative will only be available in a paid add-on in the future. If you weren't planning on removing it, only putting it in maintenance mode, that would be different. The intent to remove makes this something that we need to treat as a breaking change from the beginning. We are supposed to get the exception approved before the deprecation notice goes out, so we need to figure out how we are going to answer the questions required to get an exception.

Add artifact_registry product category under the package stage.

Needed for infrastructure labels when onboarding to Runway GKE, and later for metrics (including error budget).

Related to gitlab-org/gitlab#591832

@mwager_gitlab I think that the final decision here should fall to @mclausen35 and @ajbiton. Like audit events, feature teams should be responsible for their own webhooks. Currently, the Import team owns the platform capability that enables webhooks, but each team should own what webhooks are available for their areas and what data those webhooks provide. If Mike and AJ are willing to accept the MR and any maintenance burden, then @thiagocsf and I will happily remove ourselves from the decision. The bottom line is that Import doesn't have the capacity to own all the webhooks across the product, which is what has happened historically. We are in the process of changing that, so I think that this is a good place for us to step back and let the team responsible for this area make the decision.

@trizzi This makes sense to me. I'm approving from my side.

Summary

This MR makes two key changes to the product categories:

1. Move Dependency Firewall to Software Supply Chain Security

• categories.yml: Changed dependency_firewall stage from package to software_supply_chain_security and updated its direction URL
• stages.yml: Moved dependency_firewall from the container_registry group (under package stage) to the pipeline_security group (under software_supply_chain_security stage)

This better aligns the Dependency Firewall with the supply chain security mission, alongside related categories like artifact_security and secrets_management.

2. Add new Artifact Registry category

• categories.yml: Added new artifact_registry category under the package stage, focused on the new add-on SKU for the artifact management use case
• stages.yml: Added artifact_registry to the container_registry group under the package stage