Update baseline.yaml - NEW - OSPS-DO-13 #115
Conversation
new proposed criteria around support statements Signed-off-by: CRob <[email protected]>
Co-authored-by: Puerco <[email protected]> Signed-off-by: CRob <[email protected]>
Co-authored-by: Eddie Knight <[email protected]> Signed-off-by: CRob <[email protected]>
Signed-off-by: CRob <[email protected]>
to address feedback, will split out "EoS" statements into separate criteria Signed-off-by: CRob <[email protected]>
Co-authored-by: Ben Cotton <[email protected]> Signed-off-by: CRob <[email protected]>
Signed-off-by: CRob <[email protected]>
| The project documentation MUST include a | ||
| descriptive statement about the scope and | ||
| duration of support. |
There was a problem hiding this comment.
For some projects, the scope of support is tied (for example) to specific versions. E.g. Knative has:
https://github.com/knative/community/blob/main/mechanics/RELEASE-SCHEDULE.md#upcoming-releases
Releases supported by community
Release Date EOL Min K8s Version Notes 1.16 2024-10-22 2025-04-22 1.29 1.15 2024-07-23 2025-01-21 1.28 No longer supported releases
Release Date EOL Min K8s Version Notes 1.14 2024-04-23 2024-10-22 1.28
Having a standard mechanism of communicating this would be great, but it seems like there's a gap here between "having a descriptive statement" and "users can find the descriptive statement".
I realize this is a level 1 expectation, but I'd really like to be able to verify these statements. Is the idea to use security insights here?
There was a problem hiding this comment.
I also don't see a standardized way to report EOL for a particular release branch, which seems like it's what people often actually need (I'm on 3.14 -- do I need to upgrade to 4.x, or will I get a 3.14.1?)
There was a problem hiding this comment.
Ah, this looks like it is in #117 .
new proposed criteria around support statements