RELEASING_cn.md
本文档用于说明 PaddleOCR 的标准发版流程。
当前流程支持以下两类发布：
bump patch：例如 3.4.0 -> 3.4.1bump minor：例如 3.4.x -> 3.5.0对于 bump major：
main 分支进行release/X.Y 分支进行vX.Y.Zmain 分支打正式发布标签先确认本次发布属于哪一条版本线，以及目标版本号。
示例：
3.4.1，对应分支为 release/3.43.5.0，对应分支为 release/3.5如果该版本线尚未建立，则从 main 创建对应的 release/X.Y 分支。
如果该版本线已存在，则直接切换到该分支继续发版准备。
要求：
release/X.Y 分支根据本次发布范围，从 main 将需要发布的提交按需 cherry-pick 到 release/X.Y，直到版本内容 ready。
要求：
在 release/X.Y 上完成发布前检查。
至少应包括：
确认版本 ready 后，在 release/X.Y 分支上打正式标签：
vX.Y.Z示例：
v3.4.1v3.5.0要求：
在 GitHub 上基于本次正式标签创建 Release。
如果本次发布是新的 minor 版本首发，或本次发布涉及 PaddleX 依赖变化，则在正式标签发布前后同步完成相关更新。
至少应包括：
pyproject.toml 中 paddlex 相关依赖约束是否与本次发布版本匹配完成要求：
paddlex 相关依赖约束与本次发布目标一致当一条新的 release/X.Y 发布线完成首个正式版本发布后，需要将该 release/X.Y 的 lineage 同步回 main。
这一步是当前流程中的固定步骤，每条新的 minor 发布线至少执行一次。
目的：
main 正确感知该发布线已经完成的正式版本要求：
release/X.Y 在首个正式版本发布后执行一次release/X.Y 后续如果继续发布补丁版本，通常不要求重复执行发布完成后：
main 继续进行后续开发release/X.Y 继续维护该版本线如果后续还要发布该版本线的补丁版本：
release/X.Y 上准备补丁main 按需 cherry-pick适用场景：
处理方式：
release/X.Y 分支上继续准备内容v3.4.2适用场景：
3.5.0处理方式：
main 建立新的 release/X.Yv3.5.0paddlex 相关依赖约束main当前结论：
在新的方案明确之前，不建议直接套用当前 minor/patch 的做法处理 major 发布。
每次发版前，请确认以下事项：
vX.Y.Zrelease/X.Y 的首个正式版本，发布完成后已将 lineage 同步回 mainmainrelease/X.Y 执行release/X.Y 上维护release/X.Y 在首个正式版本发布后执行一次 lineage 同步如当前流程发生调整，应同步更新本文档。