-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a "releases" page #20293
Comments
How much of this is it possible to automate? All, or nearly all, the information about the N most recent minor releases is already available in Git and in related systems. |
Agree completely, this should be automated. I would approach this manually first then look into automating the updates entirely from the patch release tooling side. |
https://github.com/kubernetes/kubernetes/releases is going to be programmatically retrievable, but it is trailing info (might be sufficient?). There is also forward looking information here https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md, which we could make structured for programmatic access. |
Long term wouldn't it be great if you can do a one-click “the next release is ready to go, make it so” and everything deploys based on that. Anyway, I agree. Largely manual first, automate later. @jimangel could this be another form of generated documentation? |
My new thinking on this: store the release data as JSON and use that to create data-driven content Options for the origin of that JSON:
|
We can start with local JSON but if we're going data-driven it might be good to sketch out what structure we want those data to have. |
Also see issue #23855 |
/triage accepted |
I just realized that the downloads page really ought to include |
Related: issue #25534 asks for the release notes to mention the release date. |
This comment has been minimized.
This comment has been minimized.
Related: #23855 is requesting a version-specific URL for the latest release notes. As of 1.19 it started just using https://kubernetes.io/docs/setup/release/notes/, which can change (as it just did a few days ago from 1.19 to 1.20), which makes it difficult for others to link to it and have the content stay relevant for a specific release. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
I spotted https://example.docsy.dev/blog/releases/ (based on https://github.com/google/docsy-example/tree/master/content/en/blog/releases) |
/remove-lifecycle stale |
Create a "releases" page that is up to date with our releases; including links to release notes and support timelines.
Something very similar to:
Originally I was thinking this would be a good candidate to track and update in
config.toml
. But given the lack of change or reuse it should be ok to update statically in a markdown doc.master
(k8s.io) on non-master branched netlify sites (ex: https://v1-17.docs.kubernetes.io/)/kind feature
/cc @kubernetes/release-engineering @kubernetes/sig-docs-en-owners
/cc @savitharaghunathan
/priority important-soon
/sig release
/sig docs
/language en
/assign
There was some chatter in the comments on this semi-related PR: #18173 (comment)
The text was updated successfully, but these errors were encountered: