Patch Versions for Second-Generation Managed Packages

Package versions follow a major.minor.patch.build number format. Any package version number that contains a non-zero patch number is a patch version. For example, 1.1.2.5 is a patch version, but 1.1.0.4 isn’t.

Patch versions are intended for small changes like a fixing a bug. You can’t:

• Add package components.
• Delete existing package components.
• Change the API and dynamic Apex access controls.
• Deprecate any Apex code.
• Add new Apex class relationships, such as extends.
• Add Apex access modifiers, such as virtual or global.
• Add features, settings, package dependencies, or web services.
• Change a component from protected to global.
• Change the visibility of CustomSettings or CustomMetadataType from protected to public.

When creating a patch version, you must specify the package ancestor. The major and minor numbers of the patch version and the package ancestor must match. And the specified package ancestor must be managed-released.

You can specify another patch version as the package ancestor of a patch version. But you can’t specify a patch version as a direct ancestor of a non-patch version. Instead, use the keyword “ancestorVersion" : "HIGHEST”, or specify a non-patch version as the ancestor.

Installed patch versions inherit the upgrade path of the non-patch version with the same major and minor number. For example, patch version 1.0.3 has the same upgrade path as 1.0.0. See Specify a Package Ancestor in the Project File for a Second-Generation Managed Package for more information about how to specify a package ancestor.

When you create a patch version, the patch automatically inherits the features and settings defined in the package ancestor’s scratch org definition file. To create a patch, follow the same steps as you do when you create a package version, and increment the patch number.