Proposal: Rename Dependency Proxy features to better match functionality
Problem
We now have two similarly named features, called:
- Dependency Proxy (for containers)
- Dependency Proxy for packages (newly added)
These are both internally seen as "Pull through caches" for either containers or packages. For example with the container registry, you can attempt to fetch a container image from the registry, and if it doesn't exist in the cache, the registry pulls it from the Docker Hub. Then the next time you try to fetch it, the registry can use the cached version and skip the external request, speeding everything up and saving on bandwidth.
This can also be explained as a kind of proxy service, but I'm not sure that calling it a "Dependency Proxy" makes the functionality intuitively understood. I've explained to people (internal users) that we have this feature (they had no idea) and had to explain what it does as it wasn't clear from the name.
Also, now that we have two kinds of Dependency Proxy's, it's hard to differentiate between the two. Especially in admin settings and the docs. For example, this admin setting is for the "Dependency proxy", but it's not clear if it applies to the Container registry version, The package version, or both: https://docs.gitlab.com/ee/administration/packages/dependency_proxy.html#turn-off-the-dependency-proxy
Proposal
We should consider renaming the feature to be more understandable, and potentially easier for potential users to find when searching for this functionality.
Naming brainstorming:
-
Registry pull-through cache
(or caching):- Container registry pull-through cache (or caching)
- Package registry pull-through cache (or caching)
-
Registry proxy
(optionally: service)- Container registry proxy (or proxy service)
- Package registry proxy (or proxy service)
- Other?
Process
-
Rename user-facing UI/Settings and docs. -
Announce change in release post/blog/something. -
Clean up tech debt by updating code to align with user-facing naming.