---
schema_version: "1"
id: 42e92650b3dacc21e3f88ffba5a525c4fb1c30e3e0eb270048e1c79f1a6751f4
title: Work with Patch Versions
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/platform-pkg-exchange/managed_packaging/guides/first-generation/packaging-patches-about.md
canonical_url: https://developer.salesforce.com/docs/platform/pkg1-dev/guide/packaging-patches-about.html
source_site: developer.salesforce.com
content_type: documentation
content_hash: 033f232fad0c1208770885ca4b0e08ed7677c0530c7b2c4598d1ce0e59b71075
products:
  - First-Generation Managed Packaging Developer Guide
  - merged-docs
---

# Work with Patch Versions

A patch version enables a developer to change the functionality of existing components in a managed package. Subscribers experience no visible changes to the package. Patches are minor upgrades to a Managed - Released package and only used for fixing bugs or other errors.

**note:** To enable patch versioning, contact [Salesforce Partner Support](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/pkg2_feature_enablement.htm) and request patch versioning be enabled in the org where you created the namespace for the package. Patch versioning is available only to packages that have passed AgentExchange security review.

Subscribers can install patch upgrades just like they would any other package version. However, you can also distribute a patch by using [push upgrades](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/packaging_push_about.htm).

When you create a patch, the _patchNumber_ on a package's Version Number increments by one. For example, suppose that you release a package with the version number 2.0. When you release a patch, the number changes to 2.0.1. This value can't be changed manually.

## Patch Development Organizations

Every patch is developed in a patch development org, which is the org where patch versions are developed, maintained, and uploaded. To start developing a patch, create a package version. See [Create and Upload Patches in First-Generation Managed Packages](https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/patches_creating.htm#patches_creating). Patch development orgs are necessary to permit developers to change existing components without causing incompatibilities between existing subscriber installations.

A package development org can upload an unlimited number of patches. Only one patch development org can exist per major.minor release of your package. A patch development org for a package with a version number of 4.2 can only work on patches such as 4.2.1, 4.2.2, 4.2.3, and so on. It doesn’t work on version 4.1 or 4.3.

## Integrating Patch Development


The following diagram illustrates the workflow of creating a patch and integrating any work into future versions:After version 2.0 is released, the developer creates a patch. The package version number in the patch development org starts at 2.0.1. As the main development org moves towards a released version of 3.0, a second patch is created for 2.0.2. Finally, the developer merges the changes between the main development org, and the patch development org, and releases the package as version 3.0.


![Flow diagram of patch uploads](https://developer.salesforce.com/media/pkg1_dev/patches_flow.png "Patch Development Workflow")

Git source control is the best way to monitor your package versions. To learn about Git, complete the [Git and GitHub Basics](https://trailhead.salesforce.com/en/content/learn/modules/git-and-git-hub-basics) Trailhead module.

Version control is integrated into Visual Studio Code. See [Salesforce Extensions for Visual Studio Code](https://developer.salesforce.com/tools/vscode) and [Version Control in Visual Studio Code](https://code.visualstudio.com/docs/editor/versioncontrol) for details.