paulpas related-skills: cncf-argo, cncf-aws-dynamodb, cncf-aws-ec2, cncf-aws-eks
CNCF Release Process
Creates RELEASES.md documenting the project's versioning scheme, release cadence, supported versions, artifact signing, and publication locations.
When to Use
Use when:
- Project has no
RELEASES.mdor equivalent release process document - Release process exists only as tribal knowledge and has never been written down
- Preparing a CNCF incubation or graduation application
- Current
RELEASES.mdlacks versioning policy, artifact signing, or supported-versions guidance - Onboarding a new release manager
Do NOT use when:
- Project is a specification or documentation-only project with no compiled artifacts — adapt the document to describe the specification publication process instead
Steps
Check for an existing file. If GitHub MCP available:
github_get_contentspath=RELEASES.md Otherwise:gh api repos/{owner}/{repo}/contents/RELEASES.mdIf it exists, read it and identify gaps before editing.Document the versioning scheme. State whether the project uses Semantic Versioning or Calendar Versioning. Define concretely what triggers each component (breaking change → MAJOR, new feature → MINOR, bug fix → PATCH). Define pre-release labels if used (
alpha,beta,rc) and their promotion criteria.Document the release cadence. State whether releases are time-based (e.g., minor every 12 weeks) or feature-based. Include guidance on unscheduled patch/security releases. "Releases are made as needed" is acceptable if stated explicitly.
Define supported versions and backport policy. List which release lines receive bug fixes and security backports. This table must be consistent with
SECURITY.md. ⚠️ Inconsistency between these two files is a common graduation blocker — define the policy in one file and reference it from the other.State release authority. Identify which role (maintainer, release manager) is authorized to publish releases. Link to
MAINTAINERS.md. If a separate release team exists, link to its charter.Write the end-to-end release checklist. A numbered list a release manager can execute verbatim. Cover at minimum: branch cut, changelog, version bump, signed git tag (
git tag -s), CI build trigger, artifact signing (cosign or SLSA provenance), publication (GitHub Releases, container registry, language registries), and announcement (mailing list, Slack). ⚠️ Prose descriptions cannot be executed reliably — use a numbered list.List all publication locations. GitHub Releases URL, container registry, Helm chart repo, language package registries. Include the exact pull command for each artifact.
Document artifact verification. Explain how users verify checksums, cosign signatures, or SLSA provenance. Provide copy-pasteable example commands. ⚠️ Unsigned artifacts are a graduation blocker — cosign or SLSA level 1+ required.
Cross-link and validate consistency. Add links from
RELEASES.mdtoSECURITY.md,MAINTAINERS.md,CONTRIBUTING.md, and the CI release workflow file. Add a link toRELEASES.mdfromREADME.md.
Checklist
-
RELEASES.mdexists in the repository root - Versioning scheme named with definitions for each component
- Release cadence stated
- Supported versions and backport policy defined and consistent with
SECURITY.md(graduation) - Release authority identified, linked to
MAINTAINERS.md(graduation) - End-to-end release steps written as a numbered checklist (graduation)
- Artifact signing documented with verification commands (graduation)
- All publication locations listed with URLs or pull commands (graduation)
- Breaking changes policy stated
-
README.mdlinks toRELEASES.md - CI release workflow file is linked from
RELEASES.md
Knowledge Reference
- CNCF Release Process: https://contribute.cncf.io/maintainers/github/releases/
- Semantic Versioning: https://semver.org/
- Calendar Versioning: https://calver.org/
- OpenSSF Best Practices: https://openssf.org/best-practices/
Constraints
MUST DO
- Cite authoritative primary sources (official documentation, RFCs, standards bodies) — avoid secondary or blog references
- Include version-specific guidance when the reference topic has significant version-dependent behavior
- Structure reference content with clear navigation: overview first, then detailed subsections organized by use case
- Keep examples minimal and self-contained so readers can copy-paste without needing external context
MUST NOT DO
- Do not present opinionated practices as facts — distinguish between standards, recommendations, and personal preferences
- Avoid outdated API references or deprecated patterns; explicitly note version requirements for each code example
- Never include incomplete or pseudocode examples in reference materials — all examples should be runnable
- Do not conflate different product versions when documenting features that vary across releases