Promotion is the last gate before customers can install. Do the checks first, because the command takes seconds and cannot be taken back.
- Enable the promote permission in the Dev Hub
The Dev Hub user needs the Promote a package version to released permission. Salesforce suggests a dedicated permission set rather than editing profiles.
- Validate the version in a real org
Install the beta into a scratch org or throwaway sandbox. Run your regression tests and confirm the upgrade from the last released version behaves.
- Read the coverage figure off the version
Check what the package version recorded. If it is missing, under the bar, or a trigger is untested, this artifact needs rebuilding.
- Confirm dependencies are already released
Look at the dependency section of your sfdx-project.json. A base package version still in beta means the extension has to be rebuilt, not just promoted.
- Run sf package version promote
Pass the 04t ID or alias to --package and your Dev Hub to --target-dev-hub. Answer the prompt, or pass --no-prompt in a pipeline.
- Verify and record the release
Confirm the release status now reads true. Tag the commit that produced it, and publish the release note before sharing the install URL.
The 04t ID of the package version, or an alias defined in your sfdx-project.json file.
The Dev Hub username or alias that owns the package. Required, unless the target-dev-hub configuration variable is already set.
Skips the confirmation question. Required for unattended CI runs, and risky on a laptop.
Pins the API version used for the request. Rarely needed outside a version-locked pipeline.
- Beta versions install into scratch orgs and sandboxes only, which is why a dependency must reach released before the version depending on it is built.
- Without the promote permission the command fails with a Dev Hub permissions error that says nothing about your package.
- Promotion is scoped to one version number. 2.4.0 and 2.4.1 each need their own call; there is no bulk form.
