diff --git a/.claude/skills/yabgp-release-workflow/SKILL.md b/.claude/skills/yabgp-release-workflow/SKILL.md new file mode 100644 index 0000000..c7d0185 --- /dev/null +++ b/.claude/skills/yabgp-release-workflow/SKILL.md @@ -0,0 +1,142 @@ +--- +name: yabgp-release-workflow +description: This document defines the development, version management, and release workflow for the yabgp project. All contributors and maintainers must adhere to these guidelines. +--- + +# YABGP Development Workflow and Versioning Standards + +## Core Principles + +1. **Branch Management**: + * `master`: Main development branch, always contains the latest development code. + * `stable/X.Y.x`: Stable release branch, used for maintaining released versions (e.g., `stable/0.9.x`). +2. **Versioning Standards**: + * Follows [PEP 440](https://packaging.pythonlang.cn/en/latest/specifications/version-specifiers/#) standards. + * Version number is defined in the `yabgp/__init__.py` file. + +--- + +## Detailed Workflow + +### I. Development Phase + +* **Current Status**: Working on the next feature release (e.g., `0.9.0`). +* **Version Number**: The version on the `master` branch should have a `.dev0` suffix (e.g., `0.9.0.dev0`). +* **Workflow**: + 1. Developer forks the project to their personal repository. + 2. Create a feature branch based on `master`. + 3. After development is complete, submit a Pull Request (PR) to the `master` branch of `smartbgp/yabgp`. + 4. Merge after review approval. + +### II. Testing Phase + +* **Trigger**: Feature development is basically complete, ready for the code freeze and testing period. +* **Workflow**: + 1. **Tagging**: After code merge, create a TAG on the corresponding commit in the `master` branch (e.g., `v0.9.0a1`). + 2. **Iteration**: If bugs are found, fix them and repeat the above step, incrementing the suffix (e.g., `0.9.0a2`, `0.9.0a3`, etc.). + +### III. Release Phase + +* **Trigger**: Testing passed, ready to release the official version. +* **Workflow**: + 1. **Lock Version**: Maintainer submits a PR to change `yabgp/__init__.py` to the official version number (remove suffix, e.g., `0.9.0`). + 2. **Merge and Branch**: After the PR is merged into `master`: + * Create a new stable branch based on this commit: `stable/0.9.x`. + * Create an official TAG on the `stable/0.9.x` branch: `v0.9.0`. + 3. **Start Next Cycle**: Submit a new PR on the `master` branch to update the version number to the next development version (e.g., `0.10.0.dev0`) to distinguish released code from new development code. + +### IV. Maintenance Phase (Hotfix) + +* **Scenario**: A serious bug is found in a released version (e.g., `0.9.0`). +* **Workflow**: + 1. Submit fix code on the `stable/0.9.x` branch. + 2. Update the version number on `stable/0.9.x` to `0.9.1`. + 3. Create TAG `v0.9.1` and release. + 4. **Important**: Cherry-pick or merge the fix code back to the `master` branch (if `master` also has this bug). + +--- + +### Version Lifecycle Table + +| Phase | Branch | `__version__` | TAG | Action | +|---|---|---|---|---| +| Development | `master` | `0.9.0.dev0` | - | Developer fork → Develop → PR → Merge | +| Testing | `master` | `0.9.0.dev0` | `0.9.0a1`, `0.9.0a2` | Create TAG on stable commit | +| Release | `master` | `0.9.0` | - | Remove `.dev0`, Merge PR | +| Release | `stable/0.9.x` | `0.9.0` | `0.9.0` | Create stable branch, create official TAG | +| Next Version | `master` | `0.10.0.dev0` | - | Update version to next dev version | + +--- + +### Flowchart + +``` +┌─────────────────────────────────────────────────────────────────────────────┐ +│ YABGP Release Workflow │ +├─────────────────────────────────────────────────────────────────────────────┤ +│ │ +│ master branch │ +│ ═══════════════════════════════════════════════════════════════════════► │ +│ │ │ │ │ │ │ │ +│ │ 0.9.0 │ feat A │ feat B │ bugfix │ 0.9.0 │ 0.10.0 │ +│ │ .dev0 │ │ │ │ (remove │ .dev0 │ +│ │ │ │ │ │ dev0) │ │ +│ │ │ ▼ ▼ │ │ │ +│ │ │ TAG:0.9.0a1 TAG:0.9.0a2│ │ │ +│ │ │ │ │ │ +│ │ │ ▼ │ │ +│ │ │ ┌────────┴────────┐│ │ +│ │ │ │ stable/0.9.x ││ │ +│ │ │ │ ════════════► ││ │ +│ │ │ │ │ ││ │ +│ │ │ │ TAG:0.9.0 ││ │ +│ │ │ └─────────────────┘│ │ +│ │ +└─────────────────────────────────────────────────────────────────────────────┘ +``` + +--- + +## Version Number Quick Reference + +### Patch Release + +``` +Development: 0.9.1.dev0 +Testing: TAG 0.9.1a1, 0.9.1a2 +Release: Branch stable/0.9.x, TAG 0.9.1 +``` + +### Minor Release + +``` +Development: 0.10.0.dev0 +Testing: TAG 0.10.0a1, 0.10.0a2 +Release: Branch stable/0.10.x, TAG 0.10.0 +``` + +## Checklist + +### Before Developer Submits PR + +- [ ] Code is based on the latest `master` branch +- [ ] Local tests passed +- [ ] Version number not modified + +### Before Maintainer Creates Test TAG + +- [ ] Code is based on the latest `master` branch +- [ ] TAG name follows standards (e.g., `0.9.0a1`) + +### Before Maintainer Releases Official Version + +- [ ] Version number updated from `.dev0` to official version +- [ ] `stable/X.Y.x` branch created +- [ ] Official TAG created on `stable/X.Y.x` branch +- [ ] `master` branch version updated to next development version + +## References + +- [PEP 440 - Version Identification and Dependency Specification](https://peps.python.org/pep-0440/) +- [Python Packaging User Guide - Version Specifiers](https://packaging.python.org/en/latest/specifications/version-specifiers/) +- [Semantic Versioning 2.0.0](https://semver.org/) diff --git a/.claude/skills/yabgp-release-workflow/SKILL_zh_CN.md b/.claude/skills/yabgp-release-workflow/SKILL_zh_CN.md new file mode 100644 index 0000000..802d148 --- /dev/null +++ b/.claude/skills/yabgp-release-workflow/SKILL_zh_CN.md @@ -0,0 +1,142 @@ +--- +name: yabgp-release-workflow +description: 本文档定义了 yabgp 项目的开发、版本管理及发布流程。所有贡献者和维护者请务必遵守。 +--- + +# YABGP 开发流程与版本号管理规范 + +## 核心原则 + +1. **分支管理**： + * `master`：主开发分支，始终包含最新的开发代码。 + * `stable/X.Y.x`：稳定发布分支，用于维护已发布的版本（如 `stable/0.9.x`）。 +2. **版本号规范**： + * 遵循 [PEP 440](https://packaging.pythonlang.cn/en/latest/specifications/version-specifiers/#) 标准。 + * 版本号定义在 `yabgp/__init__.py` 文件中。 + +--- + +## 详细流程 + +### 一、开发阶段 (Development) + +* **当前状态**：致力于下一个功能版本（例如 `0.9.0`）。 +* **版本号**：`master` 分支上的版本号应带有 `.dev0` 后缀（例如 `0.9.0.dev0`）。 +* **操作流程**： + 1. 开发者 Fork 项目到个人仓库。 + 2. 基于 `master` 分支创建功能分支。 + 3. 完成开发后，提交 Pull Request (PR) 到 `smartbgp/yabgp` 的 `master` 分支。 + 4. Review 通过后合并。 + +### 二、测试阶段 (Testing) + +* **触发条件**：功能开发基本完成，准备进入冻结测试期。 +* **操作流程**： + 1. **打标签 (Tag)**：代码合并后，在 `master` 分支的对应 commit 上打 TAG（如 `v0.9.0a1`）。 + 2. **迭代**：如果发现 Bug，修复后重复上述步骤，递增后缀（如 `0.9.0a2`, `0.9.0a3` 等）。 + +### 三、发布阶段 (Release) + +* **触发条件**：测试通过，准备发布正式版。 +* **操作流程**： + 1. **锁定版本**：维护者提交 PR，将 `yabgp/__init__.py` 修改为正式版本号（移除后缀，如 `0.9.0`）。 + 2. **合并与分支**：PR 合并到 `master` 后： + * 基于此 Commit 创建新的稳定分支：`stable/0.9.x`。 + * 在 `stable/0.9.x` 分支上打正式 TAG：`v0.9.0`。 + 3. **开启下一周期**：在 `master` 分支上提交新的 PR，将版本号更新为下一个开发版本（如 `0.10.0.dev0`），以区分已发布代码和新开发代码。 + +### 四、维护阶段 (Maintenance/Hotfix) + +* **场景**：已发布的版本（如 `0.9.0`）发现严重 Bug。 +* **操作流程**： + 1. 在 `stable/0.9.x` 分支上提交修复代码。 + 2. 更新 `stable/0.9.x` 上的版本号为 `0.9.1`。 + 3. 打 TAG `v0.9.1` 并发布。 + 4. **重要**：将修复代码 Cherry-pick 或合并回 `master` 分支（如果 `master` 也存在此 Bug）。 + +--- + +### 版本号生命周期表格 + +| 阶段 | 分支 | `__version__` | TAG | 操作 | +|------|------|---------------|-----|------| +| 开发 | `master` | `0.9.0.dev0` | - | 开发者 fork → 开发 → PR → 合并 | +| 测试 | `master` | `0.9.0.dev0` | `0.9.0a1`, `0.9.0a2` | 在稳定 commit 上打 TAG | +| 发布 | `master` | `0.9.0` | - | 移除 `.dev0`，PR 合并 | +| 发布 | `stable/0.9.x` | `0.9.0` | `0.9.0` | 创建 stable 分支，打正式 TAG | +| 下一版本 | `master` | `0.10.0.dev0` | - | 更新版本号为下一开发版 | + +--- + +### 流程图 + +``` +┌─────────────────────────────────────────────────────────────────────────────┐ +│ YABGP 版本发布流程 │ +├─────────────────────────────────────────────────────────────────────────────┤ +│ │ +│ master 分支 │ +│ ═══════════════════════════════════════════════════════════════════════► │ +│ │ │ │ │ │ │ │ +│ │ 0.9.0 │ feat A │ feat B │ bugfix │ 0.9.0 │ 0.10.0 │ +│ │ .dev0 │ │ │ │ (移除 │ .dev0 │ +│ │ │ │ │ │ dev0) │ │ +│ │ │ ▼ ▼ │ │ │ +│ │ │ TAG:0.9.0a1 TAG:0.9.0a2│ │ │ +│ │ │ │ │ │ +│ │ │ ▼ │ │ +│ │ │ ┌────────┴────────┐│ │ +│ │ │ │ stable/0.9.x ││ │ +│ │ │ │ ════════════► ││ │ +│ │ │ │ │ ││ │ +│ │ │ │ TAG:0.9.0 ││ │ +│ │ │ └─────────────────┘│ │ +│ │ +└─────────────────────────────────────────────────────────────────────────────┘ +``` + +--- + +## 版本号示例速查 + +### 小版本更新 (Patch Release) + +``` +开发阶段: 0.9.1.dev0 +测试阶段: TAG 0.9.1a1, 0.9.1a2 +发布阶段: Branch stable/0.9.x, TAG 0.9.1 +``` + +### 次版本更新 (Minor Release) + +``` +开发阶段: 0.10.0.dev0 +测试阶段: TAG 0.10.0a1, 0.10.0a2 +发布阶段: Branch stable/0.10.x, TAG 0.10.0 +``` + +## 检查清单 + +### 开发者提交 PR 前 + +- [ ] 代码基于最新的 `master` 分支 +- [ ] 本地测试通过 +- [ ] 未修改版本号 + +### 维护者打测试 TAG 前 + +- [ ] 代码基于最新的 `master` 分支 +- [ ] TAG 名称符合规范（如 `0.9.0a1`） + +### 维护者发布正式版前 + +- [ ] 版本号已从 `.dev0` 更新为正式版 +- [ ] 已创建 `stable/X.Y.x` 分支 +- [ ] 已在 `stable/X.Y.x` 分支上打正式版 TAG +- [ ] `master` 分支版本号更新为下一开发版本 + +## 参考资料 + +- [PEP 440 - Version Identification and Dependency Specification](https://peps.python.org/pep-0440/) +- [Python Packaging User Guide - Version Specifiers](https://packaging.python.org/en/latest/specifications/version-specifiers/) +- [Semantic Versioning 2.0.0](https://semver.org/) diff --git a/yabgp/__init__.py b/yabgp/__init__.py index e78c5cc..71d2401 100644 --- a/yabgp/__init__.py +++ b/yabgp/__init__.py @@ -15,5 +15,4 @@ """version information""" -version_info = (0, 8, 3) -version = '.'.join(map(str, version_info)) +version = '0.9.0.dev0'