How to Retrieve Managed Package Components?

Question

I have a developer org where I have assigned a namespace and created a 1st generation managed package. I’ve uploaded a few released package versions, with the most recent one being over a year ago. Since then, I’ve made several bug fixes and added new features to the package. Now, I am preparing to upload a new version of the package.

I need to create release notes, but I’ve lost track of all the changes made between the last released version and the current state of the org. I haven’t been using any version control systems like Git or similar.

Given that I own the org, the code, and the package, is there a way to retrieve the components (Apex classes, Flows, etc.) from the last released version of my managed package so that I can compare it with the current state of the org and document the differences locally?

Answer

Unfortunately, Salesforce doesn’t offer a built-in method to directly retrieve the exact components of a specific managed package version from within your org once it’s been uploaded. However, there are ways you can still achieve the comparison between your last released package version and the current state of your org.

Steps to Compare Components:

Retrieve the Last Released Version of the Managed Package:

Salesforce doesn’t allow you to easily export the components of a specific version of a managed package directly. However, since you’re the owner of the package, you can retrieve all the components from the org at the time of the last release. You can use Salesforce DX or Metadata API to pull the components from your org, but the process will require a bit of manual work to pinpoint exactly which components were in that specific release.

Use Salesforce DX or Force.com IDE:

Salesforce DX is the modern way to retrieve metadata from your Salesforce org. By running commands like sfdx force:source:retrieve -m "ApexClass,ApexTrigger,Flow,CustomObject" in your terminal, you can fetch all metadata for components that exist in your org. However, this will pull the current state, not the state from a specific version of the package. The Force.com IDE (or VS Code with Salesforce extensions) also allows you to retrieve metadata. You can connect to your org, retrieve all metadata, and then compare it manually.

Compare the Current Org and Last Released Version:

After retrieving the metadata of your org, you’ll have the components of your org at its current state (including any bug fixes and new features).

Manual Comparison: If you have access to the metadata from the last released version (either through backups or old deployments), you can compare this with the current state. You can use tools like Beyond Compare or WinMerge to visually spot the differences between the retrieved metadata and the older version of your package.

Version Control (Optional): Even though you’re not using version control for your package, implementing a version control system like Git for future changes will make tracking and comparing changes much easier. You can commit the current state and the components of the last released version to a Git repository to avoid this issue in the future.

Use the Package Version Metadata:

You can view details about the specific version of your package in the Installed Packages section of Salesforce Setup. However, this will only give you metadata about the installed package version (like the package name, version, and components) and not the full list of components or their current state.

Document Changes:

Once you’ve retrieved and compared the components, create the release notes manually by going through the differences in your code and metadata. This will involve looking at the changes in Apex classes, triggers, Flows, custom objects, and other components between the last release and the current state.

Consider Using a Source Control System in the Future:

As mentioned, implementing a source revision control system such as Git will be very helpful moving forward. This will allow you to track all changes to your org and package over time, making it much easier to compare versions and generate release notes automatically. You can also use Salesforce DX to push and pull code to a Git repository, which allows better management of versions and changes.

While there is no direct method to retrieve and compare components from a specific managed package version directly in Salesforce, you can still retrieve your current org’s components and manually compare them with any backups, old deployments, or previous versions you may have. Using Salesforce DX or Metadata API will help you retrieve all components from the current state, but the challenge will be determining exactly what changed between releases, unless you have a version control system or some kind of historical metadata backup in place. For future releases, implementing a source control system such as Git along with Salesforce DX will greatly simplify this process.