0

We have created a Second Generation Managed Package and published it in AppExchange and we need to release the next version with few changes in existing codes. These are the things which we don't understand?

  1. Should we create the patch version?
  2. While creating the new package version, do I need to add the entire classes and components in package xml or only the changed classes and components?
  3. Does the newly created package version will once again go into the Salesforce AppExchange Security Review process?
Improve this question

1 Answer 1

Reset to default
1
  1. You create a patch if you need to fix bugs against a previously released version and you are not adding new functionality (or more specifically not adding any new "components" - which includes custom objects, custom fields, top-level apex classes, validation rules etc.). If you are simply evolving the package, adding new functionality, it's a new major/minor version release and not a patch.
  2. The package.xml is irrelevant to managed packages. The package content is dictated by the content of the package's packageDirectory folder as defined in the sfdx-project.json.
  3. You submit through the same process but it will be auto-approved (without cost), if you want to select this version on your app exchange listing.

An example of the sfdx-project.json is below, showing how force-app directory holds the content for the "My Package" 2GP, and that the force-unpackaged directory contains non-packaged metadata used on the scratch org for development purposes only:

{
  "namespace": "something",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "58.0",
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true,
      "package": "My Package",
      "versionNumber": "1.5.0.NEXT",
      "versionDescription": "Some description",
      "ancestorId": "My [email protected]",
      "definitionFile": "config/project-scratch-def.json",
      "postInstallScript": "something.Installer",
      "dependencies": [
        {
          "package": "..."
        }
      ]
    },
    {
      "path": "force-unpackaged"
    }
  ],
  "packageAliases": {
    "My [email protected]": "04x1z0000012345ABC",
    ...
  }
}

Being a 2GP package, all metadata for the package must always appear within the package's folder. This folder's content is the "source of truth" for the content of the package, and that folder's content should come directly from version control (so meaning that version control is your packaging "source of truth" - i.e. version control contains everything that IS the package).

It may not cover all your questions in detail, but it's worth reviewing the ISV documentation plus the sfdx packaging docs.

Improve this answer
4
  • Thanks for your reply, Phil. Could you please explain this line a bit more "The package content is dictated by the content of the package's package Directory folder as defined in the sfdx-project.xml", Should the package Directory have all the components related to the package or only the components which are edited?
    – S1th
    Aug 31 at 9:42
  • @S1th answer updated.
    – Phil W
    Aug 31 at 9:59
  • Thanks Phil. Now I have created the patch version with few apex code changes.
    – S1th
    Aug 31 at 10:04
  • Hi @Phil W , I got stuck with another issue. We want to create an another Second Generation Managed Package which works only on Multi-Currency Enabled orgs and we want this package to be available for all Salesforce Editions, so while running the package creation command, we are getting various errors regarding the reference of CurrencyISOCode field in apex classes. I have posted this question, this is the link. salesforce.stackexchange.com/questions/412262/… Could you please help me.
    – S1th
    Oct 25 at 15:44

You must log in to answer this question.

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