Create a "releases" page

[jimangel]

Create a "releases" page that is up to date with our releases; including links to release notes and support timelines.

Something very similar to:

• https://wiki.ubuntu.com/Releases
• https://www.kernel.org/category/releases.html
• https://en.wikipedia.org/wiki/Kubernetes#Release_Versions
• https://golang.org/doc/devel/release.html

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.

• (optional) add support for mermaid for data visuals (like wikipedia)
• create a short code that informs to use master (k8s.io) on non-master branched netlify sites (ex: https://v1-17.docs.kubernetes.io/)
• create the page (kubernetes.io/releases ?)
• update release managers and sig docs release handbooks
• create and implement tooling supporting the patch release team
• validate new docs theme doesn't conflict
• validate no conflicts if/when LTS model is adopted

/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)

[sftim]

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.

[jimangel]

How much of this is it possible to automate?

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.

[tpepper]

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.

[sftim]

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?

[sftim]

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:

• it's already available raw from GitHub's API
• semi-manually put it in a release-metadata repo, fetch it from GitHub
• semi-manually sync it into the website repo, and commit it

[sftim]

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.

[sftim]

Also see issue #23855

[sftim]

/triage accepted

[sftim]

I just realized that the downloads page really ought to include kubectl downloads too.

[sftim]

Related: issue #25534 asks for the release notes to mention the release date.

[bergerhoffer]

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.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[sftim]

I spotted https://example.docsy.dev/blog/releases/ (based on https://github.com/google/docsy-example/tree/master/content/en/blog/releases)
I wonder if we can take this and adapt the approach?

[jimangel]

/remove-lifecycle stale