wehub-resource-sync
e904b667c6
PaddleOCR PR Tests GPU / test-pr-gpu (push) Blocked by required conditions
PaddleOCR PR Tests / test-pr (push) Blocked by required conditions
PaddleOCR PR Tests / test-pr-python (3.8) (push) Waiting to run
Build/Publish Develop Docs / deploy (push) Failing after 1s
PaddleOCR Code Style Check / check-code-style (push) Failing after 1s
PaddleOCR PR Tests GPU / detect-changes (push) Failing after 1s
PaddleOCR PR Tests GPU / test-pr-gpu-impl (push) Waiting to run
PaddleOCR PR Tests / detect-changes (push) Failing after 1s
PaddleOCR PR Tests / test-pr-python (3.13) (push) Waiting to run
PaddleOCR PR Tests / test-pr-python (3.9) (push) Waiting to run
195 lines
5.9 KiB
Markdown
195 lines
5.9 KiB
Markdown
# PaddleOCR Release SOP
|
|
|
|
[中文](./RELEASING_cn.md)
|
|
|
|
## Scope
|
|
|
|
This document describes the standard release process for PaddleOCR.
|
|
|
|
## Release Types
|
|
|
|
The current process supports the following two release types:
|
|
|
|
- `bump patch`: for example, `3.4.0 -> 3.4.1`
|
|
- `bump minor`: for example, `3.4.x -> 3.5.0`
|
|
|
|
For `bump major`:
|
|
|
|
- The current process does not directly support this scenario
|
|
- A major release process should be discussed and designed separately, for example by introducing an additional branch or a new preparation flow
|
|
|
|
## Release Principles
|
|
|
|
- Daily development happens on `main`
|
|
- Official releases are made only from `release/X.Y`
|
|
- Official tags must use `vX.Y.Z`
|
|
- Do not create official release tags on `main`
|
|
|
|
## Standard Release Process
|
|
|
|
### 1. Confirm the release target
|
|
|
|
First confirm which release line this release belongs to and what the target version is.
|
|
|
|
Examples:
|
|
|
|
- Release `3.4.1` on `release/3.4`
|
|
- Release `3.5.0` on `release/3.5`
|
|
|
|
### 2. Create or switch to the release branch
|
|
|
|
If the release line does not exist yet, create the corresponding `release/X.Y` branch from `main`.
|
|
If it already exists, switch to that branch and continue release preparation there.
|
|
|
|
Requirements:
|
|
|
|
- One minor release line corresponds to one fixed `release/X.Y` branch
|
|
- That branch should contain only the release content and patch fixes for that line
|
|
|
|
### 3. Pick release content from main
|
|
|
|
Based on the release scope, `cherry-pick` the required commits from `main` into `release/X.Y` until the release content is ready.
|
|
|
|
Requirements:
|
|
|
|
- Only pick what is needed for the current release
|
|
- Avoid bringing unrelated new features into the release branch
|
|
- If there are release-specific fixes on the release branch, keep them limited to the current release scope
|
|
|
|
### 4. Complete pre-release checks
|
|
|
|
Complete pre-release checks on `release/X.Y`.
|
|
|
|
At minimum, this should include:
|
|
|
|
- The current branch is correct
|
|
- The working tree is clean
|
|
- The version is as expected
|
|
- Key functionality is verified
|
|
- Required tests, builds, packaging, and regression checks have passed
|
|
- Release notes are ready
|
|
|
|
### 5. Create the official tag
|
|
|
|
Once the release is ready, create the official tag on `release/X.Y`:
|
|
|
|
- The tag format must be `vX.Y.Z`
|
|
|
|
Examples:
|
|
|
|
- `v3.4.1`
|
|
- `v3.5.0`
|
|
|
|
Requirements:
|
|
|
|
- The tag must be created on the release branch for the current official release
|
|
- Do not use development tags as official release tags
|
|
|
|
### 6. Publish the GitHub Release
|
|
|
|
Create a GitHub Release based on the official tag for this release.
|
|
|
|
### 7. Update dependency constraints and release notes
|
|
|
|
If this release is the first release of a new minor line, or if it changes PaddleX dependency requirements, update the related release materials before or after the official tag is published.
|
|
|
|
At minimum, this should include:
|
|
|
|
- Checking whether the `paddlex` dependency constraints in `pyproject.toml` match the target release
|
|
- Checking whether installation docs, upgrade notes, and release notes are aligned with the release version
|
|
|
|
Completion criteria:
|
|
|
|
- The `paddlex` dependency constraints match the target release
|
|
- The version information in the documentation matches the released version
|
|
|
|
### 8. Sync the release branch lineage back to main
|
|
|
|
After the first official release of a new `release/X.Y` line is completed, sync the lineage of that `release/X.Y` branch back to `main`.
|
|
|
|
This is a fixed step in the current workflow and should be done at least once for each new minor release line.
|
|
|
|
Purpose:
|
|
|
|
- Ensure `main` correctly reflects that the release line has produced an official version
|
|
- Keep subsequent development and release cadence aligned
|
|
|
|
Requirements:
|
|
|
|
- Perform this once after the first official release of each new `release/X.Y`
|
|
- For later patch releases on the same `release/X.Y`, it is usually not necessary to repeat it
|
|
|
|
### 9. Move on to the next development cycle or patch release
|
|
|
|
After the release:
|
|
|
|
- `main` continues with ongoing development
|
|
- `release/X.Y` continues to maintain that release line
|
|
|
|
If more patch releases are needed later on the same line:
|
|
|
|
- Continue preparing patches on `release/X.Y`
|
|
- `cherry-pick` from `main` as needed
|
|
- Repeat the relevant steps in this SOP
|
|
|
|
## How to Handle Different Bump Types
|
|
|
|
### Patch Release
|
|
|
|
Applicable scenarios:
|
|
|
|
- Fixing production issues
|
|
- Small compatibility fixes
|
|
- Documentation, dependency, or stability patches
|
|
|
|
How to handle it:
|
|
|
|
- Continue preparing changes on the existing `release/X.Y`
|
|
- Create the next patch tag, for example `v3.4.2`
|
|
|
|
### Minor Release
|
|
|
|
Applicable scenarios:
|
|
|
|
- Starting a new release line
|
|
- Releasing the next stable version, for example `3.5.0`
|
|
|
|
How to handle it:
|
|
|
|
- Create a new `release/X.Y` from `main`
|
|
- Prepare the release following the standard process
|
|
- Create the first official tag, for example `v3.5.0`
|
|
- Update `paddlex` dependency constraints if needed
|
|
- Sync the lineage of that release branch back to `main` after the release
|
|
|
|
### Major Release
|
|
|
|
Current conclusion:
|
|
|
|
- It is not included in this SOP for now
|
|
- A separate process needs to be discussed and designed later
|
|
|
|
Before a dedicated solution is defined, do not directly reuse the current minor/patch process for a major release.
|
|
|
|
## Release Checklist
|
|
|
|
Before each release, confirm the following:
|
|
|
|
- The target version and corresponding release branch have been confirmed
|
|
- The content on the release branch is ready
|
|
- The release scope has been finalized
|
|
- Key tests and regression checks have passed
|
|
- Release notes are ready
|
|
- The official tag uses the `vX.Y.Z` format
|
|
- The GitHub Release has been created
|
|
- If this is the first official release on `release/X.Y`, its lineage has been synced back to `main`
|
|
|
|
## Daily Maintenance Recommendations
|
|
|
|
- New features should go to `main` first
|
|
- Official releases should always be performed through `release/X.Y`
|
|
- Patch releases should always be maintained on the corresponding `release/X.Y`
|
|
- For each new `release/X.Y`, sync its lineage once after the first official release
|
|
|
|
If the current process changes, this document should be updated accordingly.
|