ewilliams28/openclaw
1
0
Fork 0
mirror of https://github.com/openclaw/openclaw.git synced 2026-08-12 21:53:00 -06:00
Code Issues Packages Projects Releases Wiki Activity

fix(doctor): enforce deprecation registry deadlines (#120868)

Browse Source
This commit is contained in:
Peter Steinberger
2026-08-08 21:19:04 -07:00
committed by GitHub
parent 642b486986
commit 26ee1b4935
13 changed files with 275 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/openclaw-changelog-update/SKILL.md
+3 -2
View File
@@ -192,8 +192,9 @@ every human `Thanks @...` attribution.
9. Check release-note side conditions:
- inspect `src/plugins/compat/registry.ts`
- inspect `src/commands/doctor/shared/deprecation-compat.ts`
- if any compatibility `removeAfter` is on/before release date, resolve it
or explicitly record the blocker before shipping
- if a deprecated compatibility record reaches `removeAfter`, remove it when
proven safe or move it to `removal-pending` and record the blocker; keep a
due `removal-pending` record only until its documented conditions are met
10. Validate and ship:
- after the manifest-driven rewrite, regenerate and verify the complete
.agents/skills/release-openclaw-maintainer/SKILL.md
+7 -5
View File
@@ -103,11 +103,13 @@ a workflow fix that the existing parent run cannot consume.
returns to the Code SHA loop.
- During release planning, inspect both `src/plugins/compat/registry.ts` and
`src/commands/doctor/shared/deprecation-compat.ts` before branching and again
before final publish. For every deprecated or removal-pending compatibility
record whose `removeAfter` date is on or before the release date, either
remove the compatibility path where safe and validate the affected tests, or
write down why removal is blocked and get explicit maintainer approval before
shipping the expired compatibility path.
before final publish. For every `deprecated` compatibility record whose
`removeAfter` date is on or before the release date, either remove the
compatibility path where safe and validate the affected tests, or change it
to `removal-pending`, document the blocker, and get explicit maintainer
approval. Revalidate every due `removal-pending` record's blocker and upgrade
conditions before shipping; keep it only with explicit maintainer approval
until those conditions are met.
- When removing deprecated runtime/config compatibility, preserve any doctor
migration, repair, or hint that is still needed by supported upgrade paths.
Doctor-side compatibility should stay tracked in