Point Release Requests in WooCommerce

:::important The formal Point Release Request (PRR) issue template is not strictly required for all point release fixes. In practice, coordinating directly with the release lead is often sufficient to get fixes included in a point release. The rest of this document remains useful for understanding what types of fixes qualify for point releases and how to prepare them in the repository. :::

Point releases address critical issues discovered in already-shipped WooCommerce versions. These are patch releases (e.g., 9.9.0 → 9.9.1) that contain only essential fixes for production environments.

Note that this process applies only to ALREADY-RELEASED VERSIONS that are in customer production environments.

Point Release Lifecycle

Point releases follow a different lifecycle than regular releases:

• Triggered by critical issues discovered after a regular release ships
• Limited scope - only critical bug fixes and security patches
• Expedited timeline - faster review and release cycle
• Backward compatibility - no breaking changes allowed

Qualifying Changes for Point Releases

Changes qualify for point releases only if they are:

• Critical bug fixes that cause data loss, security vulnerabilities, or major functionality failures
• Security patches addressing identified vulnerabilities
• Performance fixes for severe performance regressions
• Compliance fixes required for regulatory or legal compliance

Excluded from point releases:

• New features or enhancements
• Non-critical bug fixes
• Code refactoring or cleanup
• Documentation updates

Point Release Request Process

Standard Process: Critical Bug Fixes

When to use: Most point release scenarios

1. Create a pull request against the appropriate release branch (e.g., release/9.9 for a fix targeting 9.9.x releases)

2. Create a point release request issue using the point release template in the main repository

3. Provide detailed justification in the issue including:

   • Impact assessment (how many customers affected)
   • Business impact (revenue, compliance, security implications)
   • Risk assessment of the proposed fix
   • Evidence and reproduction steps

4. Wait for release lead approval - the release lead will approve the request, which automatically adds cherry-pick labels to your PR

5. Adjust branch targeting by modifying the automatically-added labels to specify which additional branches need the fix:

   • Keep cherry pick to trunk if the fix should go to trunk
   • Keep cherry pick to frozen release if the fix should go to the current frozen release
   • Remove labels for branches that don't need the fix

6. Get your pull request reviewed, tested, and merged into the target release branch

7. Automation creates cherry-pick PRs to other branches based on the labels still applied to your original PR

8. Review and merge cherry-pick PRs as soon as possible to ensure they don't delay the next release. These cherry-pick PRs are tracked with the same milestone as the original critical fix and must be merged before the point release is published.