Website: 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.

• [x] (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
• [x] validate new docs theme doesn't conflict
• [x] 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: https://github.com/kubernetes/website/pull/18173#issuecomment-609847053

[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.

[sftim]

Related: issue #23855 would like stable (aka “permalink”) URLs for release notes.

[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.