[CI] Add automated monthly PyPI release plan with hotfix support#1554
[CI] Add automated monthly PyPI release plan with hotfix support#1554stmatengss wants to merge 2 commits into
Conversation
Implements a comprehensive release automation system for Mooncake wheel packages: - Monthly automated releases (1st of each month, minor version bump) - Hotfix support via PEP 440 post versions (e.g., 0.4.0.post1) - Release manager CLI tool for version management - Complete documentation and quick reference guides Features: - Automated version bumping and git tagging - Multi-variant builds (CUDA, Non-CUDA, Python 3.10-3.13) - GitHub Release creation with auto-generated notes - PyPI publishing for both standard and hotfix releases - Backward compatible with existing tag-based releases Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering>
stmatengss
requested review from
Ann-1024,
ShangmingCai and
ykwd
as code owners
Summary of ChangesHello @stmatengss, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request establishes a robust and automated release system for Mooncake PyPI packages. It introduces scheduled monthly releases with minor version increments and a mechanism for rapid hotfix deployment using PEP 440 post versions. The changes aim to streamline the release process, reduce manual overhead, and ensure consistent, compliant package distribution, complemented by comprehensive tooling and documentation for managing releases effectively. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Ignored Files
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![github-code-quality[bot]](https://avatars.githubusercontent.com/u/9919?s=60&v=4){kind=small}
| import sys | ||
| from pathlib import Path | ||
| from typing import Tuple, Optional | ||
| from datetime import datetime |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a comprehensive automated release system for PyPI packages, including monthly scheduled releases and manual hotfix capabilities. The changes include a Python-based release manager script and extensive documentation covering the new release plan, workflows, and usage instructions.
My review focuses on the robustness of the release script and the soundness of the documented release process. I've identified a couple of areas for improvement in the release_manager.py script to enhance its reliability and remove external dependencies. More importantly, I've raised a concern about the proposed hotfix process in the documentation, which could unintentionally include unrelated changes from the main branch into a hotfix release. Addressing this is crucial for release stability.
Overall, this is a great step towards automating releases, and with a few adjustments to the script and the hotfix strategy, it will be a very solid system.
|
|
||
| ### Hotfix Release (Manual) | ||
| 1. Identify critical bug requiring immediate fix | ||
| 2. Merge fix to main branch |
There was a problem hiding this comment.
The hotfix process described here seems to imply that hotfixes are built from the main branch after a fix is merged. This is risky because it would include not just the critical fix, but also any other new features or changes that have been merged to main since the last release. A hotfix should ideally contain only the minimal necessary changes on top of the version being patched.
A safer process would be:
- Create a hotfix branch from the tag of the version that needs patching (e.g.,
git checkout -b hotfix/0.4.0 v0.4.0). - Apply (or cherry-pick) the fix to this hotfix branch.
- Run the hotfix release workflow on this branch to create and publish the
.postrelease. - Ensure the fix is also merged into
mainto be included in the next regular release.
The current documentation could lead to confusion and accidental release of unfinished features in a hotfix. Please clarify the process and ensure the workflow implements the safer approach.
| def verify_pypi_package(self, package_name: str, version: str) -> bool: | ||
| """Verify if a package version exists on PyPI.""" | ||
| try: | ||
| import requests | ||
| url = f"https://pypi.org/pypi/{package_name}/{version}/json" | ||
| response = requests.get(url, timeout=10) | ||
| return response.status_code == 200 | ||
| except Exception as e: | ||
| print(f"Warning: Could not verify PyPI package: {e}") | ||
| return False |
There was a problem hiding this comment.
This function uses the requests library, which is a third-party dependency. To keep this script self-contained and avoid requiring users to install extra packages, it's better to use the standard library's urllib module for this simple HTTP GET request. This change removes the need for requests.
def verify_pypi_package(self, package_name: str, version: str) -> bool:
"""Verify if a package version exists on PyPI."""
import urllib.request
import urllib.error
try:
url = f"https://pypi.org/pypi/{package_name}/{version}/json"
with urllib.request.urlopen(url, timeout=10) as response:
return response.status == 200
except urllib.error.HTTPError as e:
if e.code == 404:
return False
print(f"Warning: Could not verify PyPI package: {e}")
return False
except Exception as e:
print(f"Warning: Could not verify PyPI package: {e}")
return False| content = self.pyproject_path.read_text() | ||
| match = re.search(r'version = "([^"]+)"', content) | ||
| if not match: | ||
| raise ValueError("Could not find version in pyproject.toml") | ||
| return match.group(1) |
There was a problem hiding this comment.
Using regular expressions to parse pyproject.toml is brittle and can fail if the formatting changes (e.g., extra spaces, comments). A more robust approach is to use a TOML parsing library. Since this project supports Python < 3.11, you could add tomli as a development dependency to read the file. For writing, to preserve formatting and comments, a library like tomlkit is recommended. This would make both get_current_version and update_version_file more reliable.
There was a problem hiding this comment.
These files are likely auto-generated by Claude. Check whether it is necessary to include.
|
@copilot delete RELEASE_IMPLEMENTATION_SUMMARY.md |
|
@stmatengss I've opened a new pull request, #1588, to work on those changes. Once the pull request is ready, I'll request review from you. |
| name: Monthly Release | ||
|
|
||
| on: | ||
| schedule: | ||
| # Run on the 1st of every month at 00:00 UTC | ||
| - cron: '0 0 1 * *' | ||
| workflow_dispatch: | ||
| inputs: | ||
| version_type: | ||
| description: 'Version type (major, minor, patch)' | ||
| required: true | ||
| default: 'minor' | ||
| type: choice | ||
| options: | ||
| - major | ||
| - minor | ||
| - patch | ||
|
|
There was a problem hiding this comment.
Do we really need this automation release workflow? I think most of the open-source projects make a release when something important is integrated or when the main branch is stable, which is OK to cut a new release. So I think maybe we can have a hotfix release workflow, but the monthly release should be discussed and triggered manually.
There was a problem hiding this comment.
How about adding a document to formalize the monthly release workflow? We can refer to the sglang release plan.
There was a problem hiding this comment.
SGLang has a plan for a monthly release, but not fully automated. When the time is near, it makes a release if all CI (including the nightly CI) have passed.
* Initial plan * Remove RELEASE_IMPLEMENTATION_SUMMARY.md Co-authored-by: stmatengss <11641725+stmatengss@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: stmatengss <11641725+stmatengss@users.noreply.github.com>
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
| # Run on the 1st of every month at 00:00 UTC | ||
| - cron: '0 0 1 * *' |
There was a problem hiding this comment.
So I think this release automation should not be enabled until our CI has covered all the features, such as mooncake-ep test, vllm test
Implements a comprehensive release automation system for Mooncake wheel packages:
Features:
Generated with Claude Code via Happy
Description
Type of Change
How Has This Been Tested?
Checklist
./scripts/code_format.shbefore submitting.