Patches Classification

“A patch is a piece of software designed to fix problems[1] with, or update a computer program or its supporting data. This includes fixing security vulnerabilities[1] and other bugs, and improving the usability or performance. Though meant to fix problems, poorly designed patches can sometimes introduce new problems (see software regressions). In some special cases updates may knowingly break the functionality, for instance, by removing components for which the update provider is no longer licensed or disabling a device.” — from wiki

In Release Engineering, it has one methodology called Patches Management.One of the important thing is, how to classify those patches. For example, customer A may want to have its documents updated, customer B is expediting a very critical fix for security, and other customers are pursuing functional issues, or even customized fix. A well-defined Patches classification will definitely help improve the software quality.

Below are some patches terminology used by Oracle Company.

Critical Patch Update (CPU) now refers to the overall release of security fixes each quarter rather than the cumulative database security patch for the quarter. CPU are collection of security fixes for Oracle products and they are available to customers with valid support contracts. So here my suggestion is, in a software company, it should provide a CPU patch to its customers in a scheduled date. Also it is a good chance to extend its support contract and make money from this kind of proactive support. You can refer to Oracle CPU for more details.

Patch Set Updates (PSU) are the same cumulative patches that include both the security fixes and priority fixes. The key with PSUs is they are minor version upgrades (e.g., to Oracle PSU is a new patching strategy whereby the DBA can choose only ‘recommended’ and ‘proactive’ patches. PSU is a sub patch of CPU. CPU will contain both the PSU and CPU, so the DBA may choose to apply just the CPU or apply apply all patches in the PSU patch bundle (which includes additional fixes). It is more flexible.

One-off patch, it is for one off use only and if it is not urgent, customers should wait for the CPU or PSU, however if it’s urgent then customers can choose to apply a One-off patch. All of the one-off patches should get included into PSU or a majoy upgrade patches.

Bundle Patches, it is a patch with some one-offs. It can help save time to apply patches. Supposed you want to upgrade a product and it requires you to apply 10 one off DB patches, then you can just apply the bundle patch that contain those 10 one offs.

Diagnostic patches, it is intended to help diagnose or verify a fix or a collection of bug fixes. For example, if developers want to debug in customers’ site, then release engineer could release a diagnostic patch.

Interim patches/Interim patches for security bug fixes, it contain a single bug fix or a collection of bug fixes for customer-specific security bug fixes or provided as required.

You may also define a patch type as ‘Document patches‘.

Below is the information from

The Patches and Updates tab enables you to view and download recommended patches and updates for your Oracle products. You can download the following patch types:

  • Interim patches – contain a single bug fix or a collection of bug fixes provided as required

  • Interim patches for security bug fixes – contain customer-specific security bug fixes

  • Diagnostic patches – intended to help diagnose or verify a fix or a collection of bug fixes

  • Bundle Patch Updates (BPUs) – a cumulative collection of fixes for a specific product or component

  • Patch Set Updates (PSUs) – a cumulative collection of high impact, low risk, and proven fixes for a specific product or component

  • Security Patch Updates – a cumulative collection of security bug fixes

  • Sun hardware and firmware

Oracle recommends that users apply patchsets instead of individual patches. Because of the very large number of individual patches, limiting the search for patchsets provides faster results.


A well-defined patches clarification will definitely help improve the quality of customers support. And it will help development have a better control of our patches quality and project management. Development team and testing team can have a better justification of patches expedition.