Second-Generation Managed Packaging Developer Guide
jNote: This release is in preview. Features described here don’t become generally available until the latest general availability date that Salesforce announces for this release. Before then, and where features are noted as beta, pilot, or developer preview, we can’t guarantee general availability within any particular time frame or at all. Make your purchase decisions only on the basis of generally available products and features.
Recommend a Specific Package Version to Your Subscribers
When you set a package version as the recommended version, your subscribers see an Upgrade to Recommended Version option on the Installed Packages page in their org.
To set a package’s recommended version, run the sf package update CLI command and specify the package version in the --recommended-version-id flag. This example sets PackageA@1.0 as the recommended version.
1sf package update --package 0Ho.. --target-dev-hub devhub@example.com --recommended-version-id PackageA@1.0Keep in mind these requirements and considerations for setting a recommended version:
- You can set one recommended version per package.
- Only released package versions can be set as the recommended version.
- The recommended version is not required to be the latest, released version of a package.
- When you update the recommended version, the new version that you set must be a descendant of the previous version in the package ancestry. If the package versions don’t share an ancestry tree, you’ll get an error when you try to update the package’s recommended version. To bypass this error, you can use the sf package update CLI command’s --skip-ancestor-check flag.