First-Generation Managed Packaging Developer Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
First-Generation Managed Packages
Why Switch to Second-Generation Managed Packaging?
Move to 2GP: Migrate Your Managed Packages with Ease
Register a Namespace for a First-Generation Managed Package
Create a First-Generation Managed Package Using a UI
Create a First-Generation Managed Package using Salesforce DX
Enable Dev Hub and Second-Generation Managed Packaging
Limited Access License for Package Developers
Add a Limited Access User to Your Dev Hub Org
Link a Namespace to a Dev Hub Org
Scratch Orgs and Package Development
Build and Release Your App with Managed Packages
Packaging Checklist
Deploy the Package Metadata to the Packaging Org
Create a Beta Version of Your App
Install the Package in a Target Org
Create a Managed Package Version of Your App
View Information About a Package
Components Available in First-Generation Managed Packages
Behavior of Specific Metadata in First-Generation Managed Packages
Package and Test Your First-Generation Managed Package
Update Your First-Generation Managed Package
Publish Upgrades to First-Generation Managed Packages
Manage Licenses for Managed Packages
Manage Features in First-Generation Managed Packages
AppExchange App Analytics for First-Generation Managed Packages
Developing and Distributing Unmanaged Packages
PDF

Create a Managed Package Version of Your App

After your testing is done, your app is almost ready to be published in your enterprise or on AppExchange. Generate a new managed package version in your Dev Hub org.
Ensure that you’ve authorized the packaging org and can view the existing package versions.
sf org login web --instance-url https://test.salesforce.com --set-default org_alias
View the existing package versions for a specific package to get the ID for the version you want to install.
sf package1 version list --package-id 033...
To view details for all packages in the packaging org, run the command with no parameters.
More than one beta package can use the same version number. However, you can use each version number for only one managed package version. You can specify major or minor version numbers.

You can also include URLs for a post-installation script and release notes. Before you create a managed package, make sure that you’ve configured your developer settings, including the namespace prefix.

After you create a managed package version, you can’t change some attributes of Salesforce components used in the package. See: Components Available in Managed Packages for information on editable components.

Note

  1. Create the managed package. Include the --managed-released parameter. 
    sf package1 version create --package-id 033xx00000007oi --name ”Spring 22” --description ”Spring 22 Release” --version 3.2 --managed-released
    You can use other options, like --wait to specify the number of minutes to wait.
    To protect the package with an installation key, include a value for --installation-key. Then, you or a subscriber must supply the key before you can install the package in a target org.
    After the managed package version is created, you can retrieve the new package version ID using sf package1 version list.