[CNCF Graduation] Fill Release Process Gaps in Top-level Documentation (RELEASES.md)

[kfaseela]

The Buildpacks release documentation is currently scattered across component repositories and is difficult to follow as a project-wide release process:

• Top-level doc is minimal and primarily links out: https://github.com/buildpacks/community/blob/main/RELEASES.md
• Component release docs live in separate repos and use different templates/structure/terminology:
  • Pack: https://github.com/buildpacks/pack/blob/main/RELEASE.md
  • Lifecycle: https://github.com/buildpacks/lifecycle/blob/main/RELEASE.md
  • Spec: https://github.com/buildpacks/spec/blob/main/RELEASE.md

Requested fixes (project-wide)

• Update buildpacks/community/RELEASES.md to provide a consistent, project-wide overview of the release process (not just pointers).
• Define and standardize release terminology across components (e.g., stable/unstable/pre-release) if possible and how it maps to GitHub releases/tags. If this is not possible, it would be nice to at least have a standard template for RELEASE.md across components having similar sections.
• Add explicit guidance for classifying and tagging security releases at the project level.
• Document branch/platform support timelines (support window / LTS / EOL)
• Standardize what “release artifacts” means across the project (or clearly document per-component expectations) and link to artifact locations (e.g., https://github.com/buildpacks/pack/releases, https://github.com/buildpacks/spec/releases).

Goal: a reviewer or contributor should be able to understand Buildpacks release policies and participate in releases without having to reconcile differing component templates and terminology.

[jkutner]

I'm not sure I agree with this request. The release processes are specific to the components. They are not "scattered"--they are in the location that makes sense for them. The RELEASES.md in buildpacks/community points to each one, rather than copy-pasting them into one doc.

[kfaseela]

I'm not sure I agree with this request. The release processes are specific to the components. They are not "scattered"--they are in the location that makes sense for them. The RELEASES.md in buildpacks/community points to each one, rather than copy-pasting them into one doc.

@jkutner : An overall release overview at the top level would be good enough, and then the doc can link to the specific release docs per repo. The ask was majorly to see if the three release docs can have a uniform template than looking like three completely different docs. No need to copy paste everything to the top doc, they can stay where they are currently.

[jkutner]

Add explicit guidance for classifying and tagging security releases at the project level.

I don't understand this. We don't have a release for the "project" (only the components and the spec.

[kfaseela]

Add explicit guidance for classifying and tagging security releases at the project level.

I don't understand this. We don't have a release for the "project" (only the components and the spec.

document how security patch releases are produced/tagged for supported versions as specified in https://github.com/buildpacks/community?tab=security-ov-file#response-process