Here is the first-generation flow for spinning up a patch development org and shipping a fix to a released managed package. You run this from your packaging org, not a sandbox.
- Open the package and start a patch
In the packaging org Setup, go to the managed package detail and open the patch organizations section. Choose to create a new patch development organization for the package.
- Pick the major release to patch
Use the Patching Major Release dropdown to select the released version you want to fix. Only versions with a release type of Managed - Released are eligible, so beta uploads will not appear.
- Log in and write the fix
Salesforce provisions the patch org and emails the credentials. Log in, reproduce the defect, make the correction to existing components only, and update the relevant Apex tests so the fix is covered.
- Upload the patch version
From the patch org, upload the package as Managed - Released. The patch number increments automatically (for example 2.0 becomes 2.0.1), producing a version you can distribute or push to subscribers.
The dropdown that picks which released major version the patch org is built from; it sets the baseline metadata you fix against.
Must be Managed - Released for a version to be patchable; beta packages cannot be patched.
Choose between letting subscribers install the patch themselves or sending it through a push upgrade for urgent fixes.
- You cannot add or delete components in a patch org. If a fix needs a new field, class, or global method, it must go in a minor or major release instead.
- Do not add Apex extends relationships, new global or virtual modifiers, new web services, or new feature dependencies; these break the patch's upgrade-safety rules.
- Each patch org is bound to one major release. Maintaining several supported releases means creating and tracking a separate patch org for each.
- Before push-upgrading a patch to live orgs, test it against representative subscriber data, since the install happens without the customer's involvement.