Yes. The guidance shared in the documentation recommends anonymous or Individual tier users to use the convenience tags for Official Providers. For example:

crossplane xpkg install provider xpkg.upbound.io/upbound/provider-aws-s3:v1 

However, you may choose to still reference the latest release by full major.minor.patch tag scheme:

crossplane xpkg install provider xpkg.upbound.io/upbound/provider-aws-s3:v1.19.0 

For customers with a subscription to Upbound, you’re encouraged to use a pinning-and-update strategy based on the full tag scheme that makes sense for you.

Upbound advises anonymous and Individual tier users to use the vMajor tag scheme. It’s durable to the change that occurs monthly when a new version of Official Providers gets released.

Some Upbound Official Providers are downstream builds of provider source which exists upstream in crossplane-contrib. Provider-aws is an example.

While the providers share a common source, Upbound supplements Official Providers by building from a private pipeline that supplements Official Provider images with additional value-add. The community providers are free-use images built and published by the Crossplane community. Official Providers are built and published by Upbound, and have a commercial license.

The policy is currently geared towards Official Providers, but there are other package types currently published by Upbound: Configurations, Functions, and more to come.

We don’t have plans to roll out policy changes for other package types right now. We’re committed to not breaking users who’re taking dependencies on things like function-patch-and-transform. Official packages must be published by Upbound under the upbound org on the Marketplace.

Any package–whether a function, provider, etc.–whose source exists in upstream crossplane-contrib must comply with Crossplane governance policies and have public, free builds available for use by the community. That includes repos where Upbound is the maintainer.

You can migrate from Upbound Official Providers to the community provider equivalent by following these instructions:

1. Given a control plane that already has Official Providers installed on it, install the equivalent community family package with a manual revision activation policy. This is demonstrated below for provider-aws:

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: crossplane-contrib-provider-family-aws
spec:
  package: ghcr.io/crossplane-contrib/provider-family-aws:v1.20.1
  revisionActivationPolicy: Manual

Doing the above puts your control plane into the following state:

NAME                                     INSTALLED   HEALTHY   PACKAGE                                                  AGE
crossplane-contrib-provider-family-aws   False       True      ghcr.io/crossplane-contrib/provider-family-aws:v1.20.1   3s
provider-aws-s3                          True        True      xpkg.upbound.io/upbound/provider-aws-s3:v1.20.1          50s
upbound-provider-family-aws              True        True      xpkg.upbound.io/upbound/provider-family-aws:v1.20.1      46s

2. Edit the provider-aws-s3 package field to ghcr.io/crossplane-contrib/provider-aws-s3:v1.20.1.

3. Delete the upbound-provider-family-aws provider.

4. Edit the crossplane-contrib-provider-family-aws revisionActivationPolicy and set it to Automatic. This should then result in a successful migration:

NAME                                     INSTALLED   HEALTHY   PACKAGE                                                  AGE
crossplane-contrib-provider-family-aws   True        True      ghcr.io/crossplane-contrib/provider-family-aws:v1.20.1   2m50s
provider-aws-s3                          True        True      ghcr.io/crossplane-contrib/provider-aws-s3:v1.20.1       3m37s