0

When should we ideally promote a 2G managed package? We are planning to give the package to UAT and realized in order to install a new version of the package, we will have to uninstall the previous version. This could lead to data loss and asking our client to do the post deployment steps every single time.

Can we promote a version of the package before handing it to the customer for UAT? Are there any drawbacks?

2 Answers 2

2

WARNING: This is somewhat opinion-based

By not promoting the version you essentially have beta releases. As you found, betas cannot be upgraded (nor can they be used to upgrade an earlier "release" version if the org has additional dependencies, such as custom reports, that use the package).

However, by promoting a version you set various things in stone, at least on the version branch you created (via the ancestor version). While you can abandon a version branch, you will then get into the same situation as with betas; you can only upgrade a given version using a descendant version and would have to uninstall to clean up.

My suggestion would be to use tooling that can import the required test data from a stored dataset (using some data loader). If you use the right tooling you can actually export the dataset from the UAT org before refreshing it from production (or otherwise cleaning it down).

If you do this, you can generally stick with using betas, as needed.

That said, it would generally be reasonable that the package be considered production ready when going to UAT, and it should thus typically only be small changes (bug fixes) to be made thereafter - in which case you should promote when ready for UAT and then create patch releases** to fix problems found during (and after) UAT for that product version.

If you are creating the package as single-use, i.e. one that is owned and maintained by the owner of the target production org, it may be better to consider use of 2GP unlocked packages (where versioning is more-or-less irrelevant since you can easily introduce breaking changes at any time).

**: This requires enablement by Salesforce Support on your namespace org and you'll need to raise a support case for it. If you are an ISV, that means the package must first go through security review.

2

You should promote a managed package when it is production-ready.

The one thing you should be aware of is that once you promote a package you'll have to define that version as the "ancestor version" of a new package version you create, so that the platform understands that the previous version can be upgraded to this new version you are creating now. If you don't do that, the platform will not offer the upgrade option, and you'll end up in this same scenario where you need to uninstall the app and reinstall it (having to back-up all of the app's data to import it again after install).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .