
We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.
Once a managed package is uploaded as a released version, components in that version are locked and allow limited delete, edit, and remove options.
With the release of the Component Deletion feature, depending on the component type, you may be able to delete the component to remove it from the package. If the component type is not supported by the Component Deletion feature, the only way it can be removed is by reverting the package version that introduced the component back to Beta.
Note: 2GP packages cannot be reverted to beta. Reverting to beta will not allow you to remove @deprecated from a managed class, nor can deprecated classes be removed when forced to beta. Also, reverting to beta will not allow deleted components to be undeleted.
With 2GP, it's not possible to revert a managed-released version to beta. As 2GP versions are not linear like 1GP packages, to make the desired modification to a managed 2GP version, you can branch from a previous version.
To learn more about branching from a previous version, please review Package Ancestors for Second-Generation Managed Packages.
If you need to remove a managed component that is not supported by the Component Deletion feature, please refer to the Help article below for details.
Easily Revert a Released First-Generation Managed Package Version to Beta
- Make sure the required (and subsequent) version(s) are not currently installed in any org. If they are, they will have to be uninstalled for us to revert back to beta (required to revert to beta).
- You are aware the new version will need to go through security review (only for Aloha-approved / AppExchange packages that have already passed).
- You may need to pay the review fee (only for Aloha-approved / AppExchange packages that have already paid).
FAQs:
We have no way of verifying the contents within the package without a security review. When in a Beta status, Partners have the ability to modify any of the unlocked code in the package, therefore security review is needed for the new version.
The package will go through the normal review process of 6-8 weeks after a complete submission has been provided. Since the same reviewer usually handles re-tests/re-reviews of an app, turnaround is likely to be a bit quicker, but there is no guarantee.
If a new version of a package is already paid for (i.e. under the same package ID # 033, but a different package version ID # 04t) you will have to complete the payment screen again but you will not be charged again ( it's just the way our wizard is set up).
* If restructuring the package with major changes (if it's essentially a new application), a coupon may not be approved and then you will have to pay.
The new version will start with what the latest version was. In the above scenario, once a managed-released version is uploaded, it will be 1.2.
Delete Components from Managed Packages
Welcome to the ISVforce Guide
Security Review
Package Ancestors for Second-Generation Managed Packages
Easily Revert a Released First-Generation Managed Package Version to Beta
Component Deletion
000381570