[v0.7.0] Release Tracker
The v0.7.0 release is a significant milestone for the ExecutorCH project, and we are excited to share the release tracker with you. This document outlines the process for cherry-picking changes from the main branch to the release branch, ensuring that the v0.7.0 release is stable and meets the project's quality standards.
Release Schedule
The v0.7.0 release is planned to be cut from the "release/0.7" branch on June 20, 2025. The release branch will be finalized on July 18, 2025, and the intended release date is July 25, 2025.
Cherry-Pick Criteria
The cherry-pick process focuses on stability and documentation correctness. Only low-risk changes may be cherry-picked from the main branch. The following criteria will be used to determine which changes are eligible for cherry-picking:
- Critical fixes in core components: Changes to the build, exir, backends, runtime, and SDK components are eligible for cherry-picking if they are critical fixes.
- Bug fixes in demos/examples: Bug fixes in demos and examples are eligible for cherry-picking, but no new features or experiments are allowed.
- Critical bug fixes based on community feedback: Critical bug fixes based on community feedback are eligible for cherry-picking.
- Documentation improvements: Documentation improvements are eligible for cherry-picking.
- Test/CI fixes: Test and CI fixes are eligible for cherry-picking.
- Release branch specific changes: Changes specific to the release branch, such as changing version identifiers, are eligible for cherry-picking.
Cherry-Pick Process
The cherry-pick process involves the following steps:
- Ensure the PR has landed in master: The PR must have landed in the main branch. This does not apply to release-branch specific changes.
- Create a PR against the release branch: Create a PR against the release branch, but do not land it.
- Use
pytorchbot
to cherry-pick: Usepytorchbot
to cherry-pick a PR that has been committed to the main branch using the@pytorchbot cherry-pick
command. - Manually create a cherry pick PR: Alternatively, manually create a cherry pick PR using the
git
command. - Make a request: Make a request with the following format:
Link to landed trunk PR:
*
Link to release branch PR:
*
Criteria category and reasons:
*
Release Team Review
The release team will review the cherry-pick request and respond with one of the following:
- Approved: The cherry-pick is approved, and the release team will merge the PR once the tests pass.
- Denied: The cherry-pick is denied, and the reason will be provided.
- Ask for more information: The release team may ask for more information or clarification before making a decision.
HUD Link and Branch CI Status
The HUD link with branch CI status and link to the HUD will be provided here:
Versions
- 0.7.0
Cherry-Pick Criteria in Detail
The cherry-pick criteria are designed to ensure that the v0.7.0 release is stable and meets the project's quality standards. The following sections provide more detail on each of the criteria.
Critical Fixes in Core Components
Critical fixes in core components, such as the build, exir, backends, runtime, and SDK components, are eligible for cherry-picking. These changes are critical to the stability and functionality of the project and must be included in the v0.7.0 release.
Bug Fixes in Demos/Examples
Bug fixes in demos and examples are eligible for cherry-picking, but no new features or experiments are allowed. These changes are critical to ensuring that the demos and examples are stable and functional.
Critical Bug Fixes Based on Community Feedback
Critical bug fixes based on community feedback are eligible for cherry-picking. These changes are critical to addressing issues reported by the community and ensuring that the project meets their needs.
Documentation Improvements
Documentation improvements are eligible for cherry-picking. These changes are critical to ensuring that the project's documentation is accurate, up-to-date, and meets the needs of users.
Test/CI Fixes
Test and CI fixes are eligible for cherry-picking. These changes are critical to ensuring that the project's tests and CI pipeline are stable and functional.
Release Branch Specific Changes
Changes specific to the release branch, such as changing version identifiers, are eligible for cherry-picking. These changes are critical to ensuring that the release branch is stable and functional.
Cherry-Pick Process in Detail
The cherry-pick process involves the following steps:
- Ensure the PR has landed in master: The PR must have landed in the main branch. This does not apply to release-branch specific changes.
- Create a PR against the release branch: Create a PR against the release branch, but do not land it.
- Use
pytorchbot
to cherry-pick: Usepytorchbot
to cherry-pick a PR that has been committed to the main branch using the@pytorchbot cherry-pick
command. - Manually create a cherry pick PR: Alternatively, manually create a cherry pick PR using the
git
command. - Make a request: Make a request with the following format:
Link to landed trunk PR:
*
Link to release branch PR:
*
Criteria category and reasons:
*
Release Team Review in Detail
The release team will review the cherry-pick request and respond with one of the following:
- Approved: The cherry-pick is approved, and the release team will merge the PR once the tests pass.
- Denied: The cherry-pick is denied, and the reason will be provided.
- Ask for more information: The release team may ask for more information or clarification before making a decision.
HUD Link and Branch CI Status in Detail
The HUD link with branch CI status and link to the HUD will be provided here:
Versions in Detail
- 0.7.0
[v0.7.0] Release Tracker: Q&A ==============================
We've received many questions about the v0.7.0 release tracker, and we're happy to provide answers to some of the most frequently asked questions.
Q: What is the v0.7.0 release tracker?
A: The v0.7.0 release tracker is a document that outlines the process for cherry-picking changes from the main branch to the release branch, ensuring that the v0.7.0 release is stable and meets the project's quality standards.
Q: What is the purpose of the cherry-pick process?
A: The cherry-pick process is used to ensure that the v0.7.0 release is stable and meets the project's quality standards. It involves selecting changes from the main branch that are critical to the release and incorporating them into the release branch.
Q: What are the criteria for cherry-picking changes?
A: The criteria for cherry-picking changes are as follows:
- Critical fixes in core components: Changes to the build, exir, backends, runtime, and SDK components are eligible for cherry-picking if they are critical fixes.
- Bug fixes in demos/examples: Bug fixes in demos and examples are eligible for cherry-picking, but no new features or experiments are allowed.
- Critical bug fixes based on community feedback: Critical bug fixes based on community feedback are eligible for cherry-picking.
- Documentation improvements: Documentation improvements are eligible for cherry-picking.
- Test/CI fixes: Test and CI fixes are eligible for cherry-picking.
- Release branch specific changes: Changes specific to the release branch, such as changing version identifiers, are eligible for cherry-picking.
Q: How do I cherry-pick a change?
A: To cherry-pick a change, follow these steps:
- Ensure the PR has landed in master: The PR must have landed in the main branch. This does not apply to release-branch specific changes.
- Create a PR against the release branch: Create a PR against the release branch, but do not land it.
- Use
pytorchbot
to cherry-pick: Usepytorchbot
to cherry-pick a PR that has been committed to the main branch using the@pytorchbot cherry-pick
command. - Manually create a cherry pick PR: Alternatively, manually create a cherry pick PR using the
git
command. - Make a request: Make a request with the following format:
Link to landed trunk PR:
*
Link to release branch PR:
*
Criteria category and reasons:
*
Q: What happens after I make a request?
A: After you make a request, the release team will review it and respond with one of the following:
- Approved: The cherry-pick is approved, and the release team will merge the PR once the tests pass.
- Denied: The cherry-pick is denied, and the reason will be provided.
- Ask for more information: The release team may ask for more information or clarification before making a decision.
Q: How do I check the status of my cherry-pick request?
A: You can check the status of your cherry-pick request by checking the HUD link with branch CI status and link to the HUD:
Q: What is the deadline for cherry-picking changes?
A: The deadline for cherry-picking changes is July 18, 2025, when the release branch will be finalized.
Q: What happens if I miss the deadline?
A: If you miss the deadline, your cherry-pick request will not be considered for the v0.7.0 release. However, you can still make a request for the next release.
Q: Can I cherry-pick changes that are not critical?
A: No, only critical changes are eligible for cherry-picking. If you have a non-critical change, you can still make a request for the next release.
Q: How do I know if my change is critical?
A: If your change is critical to the stability and functionality of the project, it is eligible for cherry-picking. If you are unsure, please consult with the release team or a project maintainer.
Q: Can I cherry-pick changes that are not in the main branch?
A: No, only changes that are in the main branch are eligible for cherry-picking. If you have a change that is not in the main branch, you can still make a request for the next release.
Q: How do I know if my cherry-pick request has been approved?
A: If your cherry-pick request has been approved, the release team will merge the PR once the tests pass. You will also receive a notification with the status of your request.
Q: Can I appeal a denied cherry-pick request?
A: Yes, you can appeal a denied cherry-pick request by providing more information or clarification. The release team will review your appeal and respond accordingly.