Pulp3 approaches this using Distributions. So, for example:
I have repo-Foo, with repo-versions /1/, /2/, and /3/. I want my clients pulling from https://pulp-instance/pulp/content/foo-PROD/ , and I want them to get what’s in /foo/3/. I’d accomplish this by creating a Publication for /foo/3/, and then creating a Distribution (named, say, “foo-prod” with a base-path of “foo-PROD” that pointed specifically to the publication I’d created in /foo/3/.
Now, next tiume I sync repo-foo from upstream, I get a /foo/4/ version. My prod-clients can’t see it - they’re pulling from a Distribution associated with /foo/3/. I can create a Publication for /foo/4/, and a Distribution and call it, say, “foo-testing”, with a base-path of “foo-LATEST” - now my test-team can install from it, without disturbing my prod-clients. When I’m done testing, I update the “foo-prod” Distribution to point to the Publication associated with /foo/4/ - and now my clients are getting the new content.
One advantage here is repo-versions are immutable - so using this path, you know that whatever the test-team signed off on, is exactly what the prod-users will get when the prod-distribution is updated to point to the tested-repo-version. Also, it happens as a single atomic operation, and very quickly - so there’s no chance for a prod-user to ask for an install “in the middle” of the update process.
Does that help?