2

At my company we have published an unmanaged Salesforce package consisting of a number of Apex classes, Apex triggers, custom objects, and additional custom fields added to the Contact object. This package is to be installed by our customers who would like to integrate Salesforce with our system.

An initial version of our unmanaged package was uploaded as " Connect Salesforce Reference v5.3.0" (version 1.0) enter image description here I have since made updates to some of the Apex classes. Customers who have already installed the original versions will manually be merging the changes.

My question is: I would like to upload a new version of the unmanaged package for customers who would like to install the package fresh for the first time. What is the preferred option:

  • Upload a new version of the unmanaged package, assigning it a new version number? (Note: this approach would also probably involve removing the version number from the package name). Going this route,
    • would it be possible to modify the unmanaged package contents before uploading the new version?
    • would the original version of the package still be available at the URL if its not deprecated?
  • Create a new unmanaged package with the new version in the package name. Upload the package?

PS: I'm aware of the inherent limitations of using an unmanaged package and am investigating the viability of migrating to unlocked packages. However, I do need a stopgap solution to being able to provide the latest version of our unmanaged package until I'm able to migrate.

1 Answer 1

1

Upload a new version of the unmanaged package, assigning it a new version number? (Note: this approach would also probably involve removing the version number from the package name). Going this route,

Yes, that's fine.

would it be possible to modify the unmanaged package contents before uploading the new version?

Yes, you can add/remove/modify any contents you'd like.

would the original version of the package still be available at the URL if its not deprecated?

Yes, it's a snapshot of the metadata as it existed upon upload, even if you delete components from your org afterwards.

Create a new unmanaged package with the new version in the package name. Upload the package?

You can do this, too, if you prefer. Since the package isn't upgradeable, there's no real benefit either way. It may take you longer to build the package, but there's no inherent difference from this point of view.

PS: I'm aware of the inherent limitations of using an unmanaged package and am investigating the viability of migrating to unlocked packages. However, I do need a stopgap solution to being able to provide the latest version of our unmanaged package until I'm able to migrate.

Why wait? You can create the package right now with minimal fuss. You already have a solution built. Just download the package, upload it as a new package version, and you're done. It should about the same time than going through the process of creating a new unmanaged package. I've built a number of packages this way already, and it's honestly not very intimidating.

2
  • Can I ask for one clarification. What do you mean exactly by: "download the package, upload it as a new package version" where am I downloading the package to... ? a different Salesforce org?
    – Omair Inam
    Commented Aug 28, 2020 at 21:46
  • 1
    @Omair Your computer: sfdx force:source:retrieve -n "My Package Name", then sfdx force:package:version:create ... (check the online docs for specifics). It's actually incredibly easy to do, though may take a bit extra if you have dependencies (e.g. settings to turn on).
    – sfdcfox
    Commented Aug 28, 2020 at 22:03

You must log in to answer this question.

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