# 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](/docs/platform/pkg2-dev/guide/sfdx-dev-dev2gp-plan-pkg-types-pkg-ids.md).
- 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.