First-Generation Managed Packaging Developer Guide

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
AgentExchange App Analytics for First-Generation Managed Packages
Developing and Distributing Unmanaged Packages
PDF

Note: 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.

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 AgentExchange. 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.
1sf 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.
1sf 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. 
    1sf 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.