Validate the release process docs

[nimbinatus]

Document the project's release process.

Should be a link to the right doc.

[mohan-shash]

I've created an initial draft of RELEASES.md to document bootc's release process for CNCF incubation. The draft is available on my fork in the add-releases-documentation branch:

Preview: https://github.com/mohan-shash/bootc/blob/add-releases-documentation/RELEASES.md

What's Documented
The draft provides documentation based on the existing automated release workflows:

• Versioning - Semantic versioning standards, adhered to strictly since v1.2.0
• Release Cadence - Weekly releases since v1.16.0, automated via scheduled GitHub Actions every Monday at 8:00 AM UTC
• Automated Process - Step-by-step explanation of how the release workflows create PRs, tag releases, and upload assets
• Release Assets - Vendor archive and source tarball for each release
• Stability Guarantees - CLI and API compatibility commitments for upgrades
• GPG Signing - How to verify release tags for authenticity

Critical Questions
Before finalizing the PR, I need input on three policy decisions that aren't currently documented anywhere:

1. Support Policy
   How long is each bootc release supported? Given the weekly cadence, I'm assuming we only support the latest release and encourage users to upgrade weekly. I do not believe we support an overlap support period, right?

2. Backporting Policy
   What changes qualify for backports to older releases? With weekly releases, it seems reasonable to say all fixes go into the next weekly release rather than backporting. Are we good with that?

3. Release Branches
   Are release branches (like release/1.16) created for long-term maintenance? The current workflows show all releases tagged directly from main, which suggests no separate branches. I want to confirm this is the intended strategy before documenting it.

Next Steps
I'd like to discuss these three questions at the community Friday meeting to get maintainer consensus, then finalize the PR accordingly.

Thoughts?

[mohan-shash]

We discussed the RELEASES.md draft at the August 7 community meeting.

Resolved
Release branches. Confirmed there are no long-lived release branches. All releases are tagged directly from main, and there are no release/X.Y branches for per-version maintenance. The doc now states this as settled.

Backporting. This follows directly from the no-branches strategy: there is no backporting process. Fixes land in the next weekly release, or in an off-cycle release from main when they can't wait. Documented as such.

Deprecations. The group agreed deprecation notices should be announced in a minor release (not a major release), with the item remaining functional until removal in a later major release. The updated draft reflects this.

Still open (need maintainer input)
Support duration. We didn't reach a decision on how long each release is supported (latest only, or latest plus previous, or a fixed window). Attendance was light, so this was deferred for broader maintainer input. Colin and others, this is the main one I'd like your call on. CNCF doesn't mandate a specific duration but does expect us to document our terms.

Deprecation advance-notice window. We agreed deprecations go in minor releases, but not on the minimum number of releases (or time) between the announcement and removal. The consensus was that the window should scale with the project's maturity, which needs a bit more discussion.

Other items that came up
SemVer discipline. There was concern that patch bumps are overused when new features ship. The draft now states that weekly releases introducing new features should use a minor bump, with patch reserved for bug-fix and security-only releases.

Experimental features. There's currently no centralized place tracking which features are experimental versus stable; today they're marked via an experimental flag on the relevant CLI command. I added a short note to the Stability Guarantees section noting experimental features are exempt from stability guarantees. Tracking them centrally is probably a separate follow-up.