From 8df8360bc2a2c55bf62c602f57565f56f0ef68fa Mon Sep 17 00:00:00 2001 From: Chris Date: Sat, 3 Oct 2026 16:48:13 +0800 Subject: [PATCH] docs(release): maintain milestones after publishing (#8317) --- .agents/skills/rustfs-release-publish/SKILL.md | 8 +++++--- .../references/post-release-updates.md | 10 +++++++++- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/.agents/skills/rustfs-release-publish/SKILL.md b/.agents/skills/rustfs-release-publish/SKILL.md index 8c6ff47a8..5579a3ac1 100644 --- a/.agents/skills/rustfs-release-publish/SKILL.md +++ b/.agents/skills/rustfs-release-publish/SKILL.md @@ -1,6 +1,6 @@ --- name: rustfs-release-publish -description: "Run the RustFS console gate, source version bump, release-branch CI, preview validation, human confirmation, final-tag publication, and post-release installation and website updates. Use only when the user explicitly asks to release or publish a RustFS version (发版/发布)." +description: "Run the RustFS console gate, source version bump, release-branch CI, preview validation, human confirmation, final-tag publication, and post-release milestone, installation, and website updates. Use only when the user explicitly asks to release or publish a RustFS version (发版/发布)." --- # RustFS Release Publish (preview-validated pipeline) @@ -28,6 +28,7 @@ check console main against its latest Release -> tag at the SAME commit (zero delta) -> re-verify CI/release -> CI deletes the -preview.N Releases (tags kept) -> verify published images -> publish Helm chart from the validated source + -> close the released version's milestone -> ensure the next version's milestone exists -> update installation references on main -> update rustfs.com announcement ``` @@ -154,9 +155,9 @@ git push origin "" - Verify the preview cleanup: `cleanup-preview-releases` must succeed, `gh release view ""` must then report `release not found` for every preview iteration of this target, and `git rev-parse "^{commit}"` must still resolve to `PREVIEW_HASH` (the tag is kept). If the job failed, delete the leftover Releases manually with `gh release delete "" --yes` and report it. - Optionally spot-check `./rustfs --version` from a final-tag artifact — it must report ``. -## Phase 7 — Installation references and website announcement +## Phase 7 — Milestones, installation references, and website announcement -Only after Phase 6 succeeds, complete [post-release updates](references/post-release-updates.md): align installation references on main, then update the existing top banner in `rustfs/rustfs.com`. A failed or incomplete publication leaves both on the previous available version. These follow-up commits never change `PREVIEW_HASH` or either release tag. Track their PR, merge, and deployment states separately from artifact publication; an open PR is not a live website update. +Only after Phase 6 succeeds, complete [post-release updates](references/post-release-updates.md): close the released version's milestone and ensure the next version's milestone exists, align installation references on main, then update the existing top banner in `rustfs/rustfs.com`. Milestone maintenance is required for every non-preview release and is independent of installation PR merges or website deployment. A failed or incomplete publication leaves milestones unchanged and installation references and the banner on the previous available version. These follow-up commits never change `PREVIEW_HASH` or either release tag. Track milestone, PR, merge, and deployment states separately from artifact publication; an open PR is not a live website update. ## Output contract @@ -166,5 +167,6 @@ Always report: - Target version, release branch, release-branch CI run and validated SHA, preview tag(s) used, `PREVIEW_HASH` (which both tags point at). - Manual confirmation gate status (`WAITING_FOR_CONFIRMATION` or `CONFIRMED`) and its exact target, preview tag, and `PREVIEW_HASH`. - Per-phase result (PASS/FAIL/BLOCKED) with key evidence: preview and final Release URLs, preview `isPrerelease`/`isLatest` state, final latest-channel state, console check results, the rc command matrix, and the preview-Release cleanup result (deleted Releases plus surviving tags). +- Released-version milestone title, URL, and verified closed state; next-version milestone title, URL, state, and whether it already existed or was created. Report missing milestones or failed checks/updates as incomplete follow-up work. - Post-release installation PR and verification results; website banner target, text, link, PR, and observed deployment state. Report any remaining merge authorization or failed deployment explicitly rather than claiming the banner is live. - Any deviation from this pipeline and why the user approved it. diff --git a/.agents/skills/rustfs-release-publish/references/post-release-updates.md b/.agents/skills/rustfs-release-publish/references/post-release-updates.md index 5797afb4a..9506f393f 100644 --- a/.agents/skills/rustfs-release-publish/references/post-release-updates.md +++ b/.agents/skills/rustfs-release-publish/references/post-release-updates.md @@ -1,7 +1,15 @@ -# Post-release Installation and Website Updates +# Post-release Milestone, Installation, and Website Updates Read only after the final non-preview tag has passed Phase 6. Tag creation or a green binary build alone is insufficient: the release assets, source archive, container images, Helm package, and applicable latest channels must be available. Preview tags never enter this phase. +## Version milestones + +1. Query all pages of both open and closed milestones in the RustFS release repository, matching titles exactly to version strings without a `v` prefix. A failed or incomplete query is not evidence that a milestone is absent; resolve the lookup before making changes. +2. Close the milestone matching the published `` if it is open; an already closed milestone needs no change. If it is missing, report the gap and continue checking the next version. Do not create a substitute for the released milestone or close/reassign its issues or PRs. +3. Use an explicitly planned next version when provided; otherwise, for a stable `X.Y.Z`, use `X.Y.(Z+1)`. For example, after `1.0.1` is published, close milestone `1.0.1` and ensure milestone `1.0.2` exists. For an alpha/beta/rc target with a trailing numeric counter, increment that counter within the same channel unless a different next version was specified. If the next version cannot be determined, ask for that version and report this follow-up as blocked. Creating a planning milestone does not confirm the target of a future release or bypass the semver gate. +4. Reuse an existing next-version milestone, whether open or closed; do not reopen it or create a duplicate. Only when the complete query confirms it is absent, create an open milestone with the exact next-version title. Do not invent a due date or description. After an uncertain creation result, query again before retrying. +5. Read back both milestones and report their titles, URLs, and actual states, including whether the next milestone was reused or created. A failed close, create, or verification leaves milestone maintenance incomplete; retry only the unfinished operation after refreshing live state. Continue independent installation and website work without moving or republishing the release tag. + ## Installation references 1. Re-read the published deliverable state before edits or a retry. If a newer release has superseded this target, do not downgrade installation references or the website announcement. Report the superseding release and leave those defaults intact.