- 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.
- 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
.
- 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.