Dealing with Salesforce Patch Development - [Managed Packages]

A patch is a .(dot)x version of an existing managed package that allows developers to change the functionality of any of the components present in the package.

How are Patches useful?

Patches should be considered as minor improvements to a Released Managed package.

  1. they are mainly used to fix bugs or other errors.
  2. Subscribers can get patch improvements just like other package versions.

Why should you go for a patch?

The basic intent behind a patch development is to go for another release development because the changes are not major like

  1. data model, or
  2. component structure level changes, or
  3. changing the global API signatures.

The reason behind not allowing such changes in the patch is, when a customer upgrades to a patch version, they should not be getting any compile-time error due to their current customizations.

How does Patch Development work?

The patch mechanism is a way to create one branch (= one patch org) from each version of the trunk (= packaging org). So with an org containing say version 1.5, a single patch org can be created that goes through versions 1.5.1, 1.5.2, 1.5.3, and so on. To make a new version as per your choice then the new version could be identical to the old version.

Now considering the fact that you should not make changes in the Data model and business logic, Salesforce has already restricted the development in a patch development org.

Any change, that can cause a compile-time error between 2 versions (either Release -patch OR patch-patch) while upgrade should not be added as part of the patch.

What are the restrictions on Patch development?

  • You can’t add package components.
  • You can’t delete existing package components.
  • API and dynamic Apex access controls can’t change for the package.
  • No deprecation of any Apex code.
  • You can’t add new Apex class relationships, such as extends.
  • You can’t add Apex access modifiers, such as virtual or global.
  • You can’t add new web services.
  • You can’t add feature dependencies.

Advantages of Patch Release

One of the main advantages of the patch version is that it can be automatically transferred to the customer’s organization that updates its installation to the new version of your package.

The following changes are allowed:

  • Adding new methods to Apex controllers
  • Extend the functionality of a Lightning Component
  • Add files to an existing static resource
  • Modify a permission set

Steps to Create a Patch Org

When you create a patch, you work at a patch development org. This is a special org that only allows changes that don’t break existing installations.

  1. From Setup, enter ‘Packages’ in the Quick Find box, then select Packages.
  2. Click the name of your managed package.
  3. On the Patch Organization tab, click New.
  4. Select the package version that you want to create a patch for in the Patching Major Release dropdown. The release type must be Managed — Released.
  5. Enter a username for a login to your patch org.
  6. Enter an email address associated with your login.
  7. Click Save.

--

--