Get Ready to Promote and Release a Second-Generation Managed Package Version

Each package version you create is a beta version, unless you promote it to the managed-released state. Beta versions can be installed in only scratch orgs and sandboxes. After you install a beta version into an org, you can’t later upgrade that installed beta version. Keep this in mind when you select which org to install and test your beta package version. If you use this sandbox as part of your release pipeline, then using a disposable scratch org is a better option to test your beta package.

A beta package version must pass a 75% code coverage requirement before it can be promoted. To learn more, see Code Coverage for Second-Generation Managed Packages.

To promote a package version to the released state, run the sf package version promote Salesforce CLI command. For step-by-step instructions on promoting a package version, see Release a Second Generation Managed Package.

After a package version is promoted, you can install it in either a production org or development orgs, and can be distributed to your customers.

For every minor package version, you can promote only one beta version. For example, if you create several beta versions of package version 2.3, only one of those versions can be promoted. After promoting package version 2.3, start your new development using version number 2.4.

After a package version is promoted to the released state, you can't reverse the promotion. If you discover you don’t want to distribute a version you promoted, you can’t reverse that version back to the beta state. To ensure that that version isn’t inadvertently shared and installed in a customer org, we recommend you use the sf package version update Salesforce CLI command and set the installation key to something cryptic and difficult to guess.