Remove use of packages-registries-v2 feature version (#51060)

content/packages/learn-github-packages/about-permissions-for-github-packages.md

@@ -9,7 +9,6 @@ versions:
 shortTitle: About permissions
 ---
 
-{% ifversion packages-registries-v2 %}
 The permissions for packages can be scoped either to a user or an organization or to a repository.
 
 ## Granular permissions for user/organization-scoped packages
@@ -23,13 +22,10 @@ The following {% data variables.product.prodname_registry %} registries support
 {% ifversion packages-nuget-v2 %}- NuGet registry{% endif %}
 {% ifversion packages-rubygems-v2 %}- RubyGems registry{% endif %}
 
-{% endif %}
+## Permissions for repository-scoped packages
 
-## Permissions for {% ifversion packages-registries-v2 %}repository-scoped {% endif %}packages
+A repository-scoped package inherits the permissions and visibility of the repository in which the package is published. You can find a package scoped to a repository by going to the main page of the repository and clicking the **Packages** link to the right of the page. {% ifversion fpt or ghec %}For more information, see "[AUTOTITLE](/packages/learn-github-packages/connecting-a-repository-to-a-package)."{% endif %}
 
-A {% ifversion packages-registries-v2 %}repository-scoped {% endif %}package inherits the permissions and visibility of the repository in which the package is published. You can find a package scoped to a repository by going to the main page of the repository and clicking the **Packages** link to the right of the page. {% ifversion fpt or ghec %}For more information, see "[AUTOTITLE](/packages/learn-github-packages/connecting-a-repository-to-a-package)."{% endif %}
-
-{% ifversion packages-registries-v2 %}
 The following {% data variables.product.prodname_registry %} registries **only** support repository-scoped permissions.
 
 {% ifversion not fpt or ghec %}- Docker registry (`docker.pkg.github.com`){% endif %}
@@ -41,18 +37,12 @@ The following {% data variables.product.prodname_registry %} registries **only**
 
 For {% ifversion ghes %}the {% data variables.product.prodname_container_registry %}{% else %}other registries{% endif %}, you can choose to allow packages to be scoped to a user or an organization, or linked to a repository. {% ifversion docker-ghcr-enterprise-migration %}For information about migration to the {% data variables.product.prodname_container_registry %}, see "[AUTOTITLE](/packages/working-with-a-github-packages-registry/migrating-to-the-container-registry-from-the-docker-registry)."{% endif %}
 
-{% endif %}
-
-{% ifversion packages-registries-v2 %}
-
 ## Visibility and access permissions for packages
 
 {% data reusables.package_registry.visibility-and-access-permissions %}
 
 For more information, see "[AUTOTITLE](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)."
 
-{% endif %}
-
 ## About scopes and permissions for package registries
 
 {% data reusables.package_registry.packages-classic-pat-only %}
@@ -84,10 +74,10 @@ For more information, see:{% ifversion fpt or ghec %}
 
 You can transfer a repository to another personal account or organization. For more information, see "[AUTOTITLE](/repositories/creating-and-managing-repositories/transferring-a-repository)."
 
-When you transfer a repository, {% ifversion packages-registries-v2 %}{% data variables.product.prodname_dotcom %} may transfer the packages associated with the repository, depending on the registry the packages belong to.
+When you transfer a repository, {% data variables.product.prodname_dotcom %} may transfer the packages associated with the repository, depending on the registry the packages belong to.
 
 - For registries that support granular permissions, packages are scoped to a personal account or organization, and the account associated with the package does not change when you transfer a repository. If you have linked a package to a repository, the link is removed when you transfer the repository to another user. Any {% ifversion fpt or ghec %}codespaces or {% endif %}{% data variables.product.prodname_actions %} workflows associated with the repository will lose access to the package. If the package inherited its access permissions from the linked repository, users will lose access to the package. For the list of these registries, see "[Granular permissions for user/organization-scoped packages](#granular-permissions-for-userorganization-scoped-packages)" above.
-- For registries that only support repository-scoped permissions, packages are published directly to repositories, and {% endif %}{% data variables.product.prodname_dotcom %} transfers the packages associated with a repository as part of the repository transfer. All billable usage associated with the packages will subsequently be billed to the new owner of the repository. If the previous repository owner is removed as a collaborator on the repository, they may no longer be able to access the packages associated with the repository.{% ifversion packages-registries-v2 %} For the list of these registries, see "[Permissions for repository-scoped packages](#permissions-for-repository-scoped-packages)" above.{% endif %}
+- For registries that only support repository-scoped permissions, packages are published directly to repositories, and {% data variables.product.prodname_dotcom %} transfers the packages associated with a repository as part of the repository transfer. All billable usage associated with the packages will subsequently be billed to the new owner of the repository. If the previous repository owner is removed as a collaborator on the repository, they may no longer be able to access the packages associated with the repository. For the list of these registries, see "[Permissions for repository-scoped packages](#permissions-for-repository-scoped-packages)" above.
 
 ## Maintaining access to packages in {% data variables.product.prodname_actions %} workflows
 

content/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility.md

@@ -13,21 +13,10 @@ shortTitle: Access control & visibility
 ---
 {% data reusables.package_registry.container-registry-ghes-beta %}
 
-{% ifversion packages-registries-v2 %}
-
 A package can inherit its visibility and access permissions from a repository, or, for registries that support granular permissions, you can set the visibility and permissions of the package separately from a repository.
 
 For the list of registries that support granular permissions, and for more information about permissions for packages, packages-related scopes for PATs, or managing permissions for your {% data variables.product.prodname_actions %} workflows, see "[AUTOTITLE](/packages/learn-github-packages/about-permissions-for-github-packages)."
 
-{% else %}
-A package inherits the permissions and visibility of the repository in which the package is published.
-
-For more information about permissions for packages, packages-related scopes for PATs, or managing permissions for your {% data variables.product.prodname_actions %} workflows, see "[AUTOTITLE](/packages/learn-github-packages/about-permissions-for-github-packages)."
-
-{% endif %}
-
-{% ifversion packages-registries-v2 %}
-
 ## About inheritance of access permissions
 
 In registries that support granular permissions, packages are scoped to a personal account or organization. In these registries, you can publish a package without linking the package to a repository, then determine who can access the package by setting access permissions and visibility in the package's settings.
@@ -44,8 +33,6 @@ If you publish a package in a registry that only supports repository-scoped perm
 
 {% data reusables.package_registry.visibility-and-access-permissions %}
 
-{% endif %}
-
 ## Configuring access to packages for your personal account
 
 If you have admin permissions to a package that's scoped to a personal account, you can assign read, write, or admin roles to other users. For more information about these permission roles, see "[About inheritance of access permissions](#about-inheritance-of-access-permissions)."
@@ -71,8 +58,6 @@ If your package is private or internal and scoped to an organization, then you c
 
 The selected users or teams will automatically be given access and don't need to accept an invitation first.
 
-{% ifversion packages-registries-v2 %}
-
 ## Selecting whether a package inherits permissions from a repository
 
 {% ifversion packages-inherit-permissions %}By default, if you publish a package that is linked to a repository, the package inherits{% else %}If you link a package to a repository, you can choose whether or not the package inherits{% endif %} the access permissions of the linked repository. We recommend you let packages inherit their permissions from a repository, because this simplifies the process of managing access to a package.
@@ -107,8 +92,6 @@ When a package inherits permissions from a repository, to grant or remove access
 {% data reusables.package_registry.package-settings-option %}
 {% data reusables.package_registry.disable-auto-inheritance-step %}
 
-{% endif %}
-
 {% ifversion packages-inherit-permissions %}
 
 ## Disabling automatic inheritance of access permissions in an organization
@@ -125,8 +108,6 @@ If you disable automatic inheritance of access permissions, new packages scoped
 
 {% endif %}
 
-{% ifversion packages-registries-v2 %}
-
 ## Ensuring workflow access to your package
 
 For packages scoped to a personal account or an organization, to ensure that a {% data variables.product.prodname_actions %} workflow has access to your package, you must give explicit access to the repository where the workflow is stored.
@@ -164,7 +145,6 @@ To further customize access to your package, see "[Configuring access to package
 {% data reusables.package_registry.package-settings-actions-access-role-repo %}
 
 To further customize access to your package, see "[Configuring access to packages for an organization](#configuring-access-to-packages-for-an-organization)."
-{% endif %}
 
 {% ifversion fpt or ghec %}
 

content/packages/learn-github-packages/deleting-and-restoring-a-package.md

@@ -54,7 +54,6 @@ With registries that support granular permissions, you can use a `GITHUB_TOKEN`
 
 ## Required permissions to delete or restore a package
 
-{% ifversion packages-registries-v2 %}
 With registries that support granular permissions, you can choose to allow packages to be scoped to a user or an organization, or linked to a repository.
 
 To delete a package that has granular permissions separate from a repository, such as container images stored at {% ifversion ghes %}`https://containers.HOSTNAME/NAMESPACE/PACKAGE-NAME`{% else %}`https://ghcr.io/NAMESPACE/PACKAGE-NAME`{% endif %}{% ifversion packages-npm-v2 %} or packages stored at `https://npm.pkg.github.com/NAMESPACE/PACKAGE-NAME`{% endif %} (where `NAMESPACE` is the name of the personal account or organization to which the package is scoped), you must have admin access to the package. For more information, see "[AUTOTITLE](/packages/learn-github-packages/about-permissions-for-github-packages)."
@@ -63,17 +62,11 @@ For packages that inherit their access permissions from repositories, you can de
 
 Some registries **only** support repository-scoped packages. For a list of these registries, see "[AUTOTITLE](/packages/learn-github-packages/about-permissions-for-github-packages#permissions-for-repository-scoped-packages)."
 
-{% else %}
-
-You can delete a package if you have admin permissions to the repository in which the package is published.
-
-{% endif %}
-
 ## Deleting a package version
 
-### Deleting a version of a {% ifversion packages-registries-v2 %}repository-scoped {% endif %}package on {% data variables.product.prodname_dotcom %}
+### Deleting a version of a repository-scoped package on {% data variables.product.prodname_dotcom %}
 
-To delete a version of a {% ifversion packages-registries-v2 %}repository-scoped {% endif %}package, you must have admin permissions to the repository in which the package is published. For more information, see "[Required permissions](#required-permissions-to-delete-or-restore-a-package)."
+To delete a version of a repository-scoped package, you must have admin permissions to the repository in which the package is published. For more information, see "[Required permissions](#required-permissions-to-delete-or-restore-a-package)."
 
 {% data reusables.repositories.navigate-to-repo %}
 {% data reusables.package_registry.packages-from-code-tab %}
@@ -82,7 +75,7 @@ To delete a version of a {% ifversion packages-registries-v2 %}repository-scoped
 {% data reusables.package_registry.package-settings-delete-versions %}
 1. To confirm deletion, type the package name and click **I understand the consequences, delete this version**.
 
-### Deleting a version of a {% ifversion packages-registries-v2 %}repository-scoped{% endif %} package with GraphQL
+### Deleting a version of a repository-scoped package with GraphQL
 
 {% data reusables.package_registry.about-graphql-support %}{% ifversion packages-rest-api %} For information on using the REST API instead, see the "[AUTOTITLE](/rest/packages)."{% endif %}
 
@@ -193,7 +186,7 @@ Once the package is restored, the package will use the same namespace it did bef
 
 ### Restoring a package in an organization
 
- You can restore a deleted package through your organization account settings, as long as the package was in a repository owned by the organization{% ifversion packages-registries-v2 %} or had granular permissions and was scoped to your organization account{% endif %}.
+ You can restore a deleted package through your organization account settings, as long as the package was in a repository owned by the organization or had granular permissions and was scoped to your organization account.
 
 To review who can restore a package in an organization, see "[Required permissions](#required-permissions-to-delete-or-restore-a-package)."
 

content/packages/learn-github-packages/introduction-to-github-packages.md

@@ -37,18 +37,8 @@ For more information about the configuration of {% data variables.product.prodna
 
 ### Overview of package permissions
 
-{% ifversion packages-registries-v2 %}
-
 The permissions for a package are either inherited from the repository where the package is hosted, or can be defined for specific users or organizations. Some registries only support permissions inherited from a repository. For a list of these registries, see "[AUTOTITLE](/packages/learn-github-packages/about-permissions-for-github-packages#permissions-for-repository-scoped-packages)." For more information on package access, see "[AUTOTITLE](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)."
 
-{% else %}
-
-Each package inherits the permissions of the repository where the package is hosted.
-
-For example, anyone with read permissions for a repository can install a package as a dependency in a project, and anyone with write permissions can publish a new package version.
-
-{% endif %}
-
 ### Overview of package visibility
 
 {% data reusables.package_registry.public-or-private-packages %}