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.
Best Practices for Second-Generation Managed Packages
We suggest that you follow these best practices when working with second-generation
managed packages.
- We recommend that you work with only one Dev Hub, and enable Dev Hub in your partner business org.
- The Dev Hub org against which you run the sf package create command becomes the owner of the package. If the Dev Hub org associated with a package expires or is deleted, its packages no longer work.
- Include the --tag option when you use the sf package version create and sf package version update commands. This option helps you keep your version control system tags in sync with specific package versions.
- Create user-friendly aliases for packaging IDs, and include those aliases in your Salesforce DX project file and when running CLI packaging commands. See: Package IDs and Aliases for Second-Generation Managed Packages.
- When adding components to your package, check the product documentation for that component to ensure that the product is generally available (GA). If you choose to package a non-GA component, it may have limitations and isn't guaranteed to GA. This scenario is particularly risky if the component can't be removed from a managed package.