In this RFC, we propose the policy aiming to guide the decision-making process for determining whether Pull Requests (PRs) should be cherry-picked onto a release branch after the release branch has been cut. The goal is to maintain the stability and predictability of releases while addressing critical issues and incorporating essential improvements.
Motivation
Cherry-picking pull requests (PRs) onto a release branch can introduce additional overhead and goes against established best practices. While cherry-picks are sometimes unavoidable, we can mitigate their necessity through well-defined policies. This proposal outlines a framework for making informed decisions about when and how to cherry-pick changes.
Proposed Policies:
The following outlines the specific scenarios under which cherry-picking pull requests (PRs) onto a release branch will be considered acceptable after the official release branch cut.
The PR is for severe/P0 bug fixing purposes
The PR is for improving unforeseen code stability or security issues
The PR has significant impact on usability improvements
The PR is related to a planned release feature urgent fix
The PR only updates documentation, not changing any code
The merge rule should be more strict as the release deadline approaches. For the first 1-2 week we can still consider taking features that's critical to the user/customer.
For features that can be turned off by a flag or not enabled by default we should consider them as safer. Features that will affect the default behavior of the PyTorch/XLA is dangerous and shouldn't be taken after release unless it is a regression fix.
The bar for the experimental feature can be lower since we set the user expection. The changes to a already stable feature should be more carefully review.
🚀 Feature
In this RFC, we propose the policy aiming to guide the decision-making process for determining whether Pull Requests (PRs) should be cherry-picked onto a release branch after the release branch has been cut. The goal is to maintain the stability and predictability of releases while addressing critical issues and incorporating essential improvements.
Motivation
Cherry-picking pull requests (PRs) onto a release branch can introduce additional overhead and goes against established best practices. While cherry-picks are sometimes unavoidable, we can mitigate their necessity through well-defined policies. This proposal outlines a framework for making informed decisions about when and how to cherry-pick changes.
Proposed Policies:
The following outlines the specific scenarios under which cherry-picking pull requests (PRs) onto a release branch will be considered acceptable after the official release branch cut.