The case for more stable betas

[de...@redhat.com]

Continuing from prior mailing threads and sig meetings, I'd like to explore how we could make our beta features more stable while allowing phased delivery of features.  I've written a small doc [1] outlining the details.  There is context and descriptions of how to phase in larger features in the doc, but I'd say the most critical sentence is

> Promotion from Beta to GA must be zero-diff for the release.  This means that Beta criteria must include all functionality, security, and testing requirements along with resolving all issues and gaps identified prior to beta.

Additional functionality needs to be separately disable-able to allow a cluster-admin to keep the function their cluster already relies on while disabling the new additions that don't function as expected.

Feel free to comment on the doc (shared with the sig-arch group) or reply in the thread.  I'd like to discuss at a future sig-arch meeting.

[1]: https://docs.google.com/document/d/1eLulBZ988bWNwrwnz9V70xVbQmHOYjrQpXRwiGmgcFM/edit?tab=t.0