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.

Patch versions are intended for minor changes. 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. Keep in mind that the major and minor version number of the patch 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. See Specify a Package Ancestor in the Project File for a Second-Generation Managed Package for more information on 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 external definition file. To create a patch, follow the same steps as you do when you create a package version, and increment the patch number.