abbyswag/qwen-code
1
0
Fork 0
mirror of https://github.com/QwenLM/qwen-code.git synced 2025-12-19 09:33:53 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update instructions for patching a release (#6871)

Browse Source 
Co-authored-by: matt korwel <matt.korwel@gmail.com>
Co-authored-by: Arya Gummadi <aryagummadi@google.com>
This commit is contained in:
Shreya Keshive
2025-08-22 21:15:03 -07:00
committed by GitHub
parent d89f7ea9b5
commit f55b294570
2 changed files with 47 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

60
docs/releases.md
View File

@@ -43,7 +43,7 @@ Each night at UTC 0000 we will auto deploy a nightly release from `main`. This w
Each Tuesday at UTC 2359 we will auto deploy a preview release of the next production release x.y.z.
- This will happen as a scheduled instance of the ‘release’ action. It will be cut off of Main.
- This will create a branch `release/x.y.z-preview.n`
- This will create a branch `release/vx.y.z-preview.n`
- We will run evals and smoke testing against this branch and the npm package. For now this should be manual smoke testing, we don't have a dedicated matrix or specific detailed process. There is work coming soon to make this more formalized and automatic see https://github.com/google-gemini/gemini-cli/issues/3788
- Users installing `@preview` will get this release as well
@@ -51,23 +51,57 @@ Each Tuesday at UTC 2359 we will auto deploy a preview release of the next produ
After one week (On the following Tuesday) with all signals a go, we will manually release at 2000 UTC via the current on-call person.
- The release action will be used with the source branch as `release/x.y.z-preview.n`
- The release action will be used with the source branch as `release/vx.y.z-preview.n`
- The version will be x.y.z
- The releaser will create and merge a pr into main with the version changes.
- Smoke tests and manual validation will be run. For now this should be manual smoke testing, we don't have a dedicated matrix or specific detailed process. There is work coming soon to make this more formalized and automatic see https://github.com/google-gemini/gemini-cli/issues/3788
## Patching releases
## Patching Releases
If a bug or feature fix is found and needed before the next weekly release is out.
If a critical bug needs to be fixed before the next scheduled release, follow this process to create a patch.
- Create a new branch from the appropriate source
- For a patch release of a preview, start with the release/x.y.z-preview.n branch and create a new branch off of that.
- For a patch release of an existing version, we'll utilize the git TAG that is automatically created with each release to ensure we pull the exact commit. The format is `v.x.y.z`. Run `git checkout vx.x.x -b &lt;hotfix branch name ideally an issue number>` to pull the tag and create a branch local.
- Verify the issue, then fix the issue, push your changes
- Do a release per the instructions above, using your branch as the base and incrementing the patch version as appropriate.
- After the release merge back to main
- For a stable release merge via PR the `release/x.y.z` branch back to main to keep version number current.
- For a preview relase, merge the `relase/x.y.z-preview.n` branch back to the `release/x.y.z-preview.n` branch to make the preview version number current. Then also cherry pick your feature commit back to main.
### 1. Create a Hotfix Branch
First, create a new branch for your fix. The source for this branch depends on whether you are patching a stable or a preview release.
- **For a stable release patch:**
Create a branch from the Git tag of the version you need to patch. Tag names are formatted as `vx.y.z`.
```bash
# Example: Create a hotfix branch for v0.2.0
git checkout v0.2.0 -b hotfix/issue-123-fix-for-v0.2.0
```
- **For a preview release patch:**
Create a branch from the existing preview release branch, which is formatted as `release/vx.y.z-preview.n`.
```bash
# Example: Create a hotfix branch for a preview release
git checkout release/v0.2.0-preview.0 && git checkout -b hotfix/issue-456-fix-for-preview
```
### 2. Implement the Fix
In your new hotfix branch, either create a new commit with the fix or cherry-pick an existing commit from the `main` branch. Merge your changes into the source of the hotfix branch (ex. https://github.com/google-gemini/gemini-cli/pull/6850).
### 3. Perform the Release
Follow the manual release process using the "Release" GitHub Actions workflow.
- **Version**: For stable patches, increment the patch version (e.g., `v0.2.0` -> `v0.2.1`). For preview patches, increment the preview number (e.g., `v0.2.0-preview.0` -> `v0.2.0-preview.1`).
- **Ref**: Use your source branch as the reference (ex. `release/v0.2.0-preview.0`)
![How to run a release](assets/release_patch.png)
### 4. Update Versions
After the hotfix is released, merge the changes back to the appropriate branch.
- **For a stable release hotfix:**
Open a pull request to merge the release branch (e.g., `release/0.2.1`) back into `main`. This keeps the version number in `main` up to date.
- **For a preview release hotfix:**
Open a pull request to merge the new preview release branch (e.g., `release/v0.2.0-preview.1`) back into the existing preview release branch (`release/v0.2.0-preview.0`) (ex. https://github.com/google-gemini/gemini-cli/pull/6868)
## Release Schedule
@@ -158,7 +192,7 @@ Each release, wether automated or manual performs the following steps:
### Failure Handling
If any step in the workflow fails, it will automatically create a new issue in the repository with the labels `bug` and `relase-failure`. The issue will contain a link to the failed workflow run for easy debugging.
If any step in the workflow fails, it will automatically create a new issue in the repository with the labels `bug` and `release-failure`. The issue will contain a link to the failed workflow run for easy debugging.
### Docker