@@ -1,10 +1,11 @@
11---
2-summary: "Release lanes, operator checklist, validation boxes, version naming, and cadence"
2+summary: "Release lanes, operator checklist, validation boxes, version naming, planned monthly support lines, and cadence"
33title: "Release policy"
44read_when:
55 - Looking for public release channel definitions
66 - Running release validation or package acceptance
77 - Looking for version naming and cadence
8+ - Planning monthly support or LTS release lines
89---
9101011OpenClaw has three public release lanes:
@@ -17,18 +18,38 @@ OpenClaw has three public release lanes:
17181819- Stable release version: `YYYY.M.D`
1920- Git tag: `vYYYY.M.D`
20-- Stable correction release version: `YYYY.M.D-N`
21+- Legacy stable correction release version: `YYYY.M.D-N`
2122- Git tag: `vYYYY.M.D-N`
2223- Beta prerelease version: `YYYY.M.D-beta.N`
2324- Git tag: `vYYYY.M.D-beta.N`
2425- Do not zero-pad month or day
2526- `latest` means the current promoted stable npm release
2627- `beta` means the current beta install target
27-- Stable and stable correction releases publish to npm `beta` by default; release operators can target `latest` explicitly, or promote a vetted beta build later
28+- Stable and legacy correction releases publish to npm `beta` by default; release operators can target `latest` explicitly, or promote a vetted beta build later
2829- Every stable OpenClaw release ships the npm package and macOS app together;
2930 beta releases normally validate and publish the npm/package path first, with
3031 mac app build/sign/notarize reserved for stable unless explicitly requested
313233+### Planned monthly support versioning
34+35+OpenClaw does not yet have an LTS or monthly support channel. Maintainers are
36+working toward SemVer-compatible monthly support lines, but the shipped update
37+channels today are still `stable`, `beta`, and `dev`.
38+39+The planned version shape is `YYYY.M.PATCH`:
40+41+- `YYYY` is the year.
42+- `M` is the monthly release line, without a leading zero.
43+- `PATCH` increments within that monthly line and can grow as high as needed.
44+45+For example, `2026.6.0`, `2026.6.1`, and `2026.6.2` would all be on the June
46+2026 line. A future monthly support dist-tag such as `stable-2026-6` or
47+`lts-2026-6` may point at that line, while `latest` continues to move quickly.
48+49+This future model replaces the need for new `YYYY.M.D-N` correction releases.
50+Existing legacy correction versions remain recognized so older packages and
51+upgrade paths keep working.
52+3253## Release cadence
33543455- Releases move beta-first
@@ -239,7 +260,7 @@ Validation` or from the `main`/release workflow ref so workflow logic and
239260`preflight_run_id` and `validate_run_id`
240261- the real publish paths promote prepared artifacts instead of rebuilding
241262 them again
242-- For stable correction releases like `YYYY.M.D-N`, the post-publish verifier
263+- For legacy stable correction releases like `YYYY.M.D-N`, the post-publish verifier
243264 also checks the same temp-prefix upgrade path from `YYYY.M.D` to `YYYY.M.D-N`
244265 so release corrections cannot silently leave older global installs on the
245266 base stable payload
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。