Add automated release page generation using content adapter

[kfess]

What this PR does

This is a draft PR to gather feedback on a Content Adapter-based release page. I'd like to hear your thoughts on whether this approach makes sense and what improvements might be needed. This PR implements dynamically generated release pages from a single YAML data source (data/releases/releases.yaml), providing a "one-stop shop" for Kubernetes release information.

Page Content

Release pages show different levels of detail based on lifecycle status:

• Actively Supported releases (v1.35): Full information including downloads, documentation, feature gates, and all patches (see: v1.35.0 deploy preview)
• Maintenance Mode releases (v1.34): Same complete information with a banner encouraging upgrade planning (see: v.1.34.3 deploy preview)
• EOL releases (v1.12): Limited to changelog and GitHub links with no direct downloads (see: v.1.12.0 deploy preview)

Individual patch releases within a series may have varying levels of detail. Older patches reference GitHub for downloads, while recent patches provide full download links and binary tables.

Limitations

I recognize this implementation is not yet production-ready. For practical use, the releases.yaml file (which is the single source of truth) needs to be automatically generated and updated. My current thinking:

• A script should be added to kubernetes/release repository (?)
• This script would generate/update the YAML file as part of the release process
• I believe every information in this page can be obtained automatically:
  • Release info (from release schedule)
  • Download URLs (predictable patterns from dl.k8s.io)
  • Container images (from registry.k8s.io)
  • Changelog URLs (predictable GitHub paths)
  • Feature Gates (from existing tooling)

Additional

Also, I'm not sure if placing HTML files in the layout is the right approach.

I'd appreciate any feedback on this direction before investing more time in polish and automation. If this approach looks reasonable, I'm happy to proceed with implementing the automation for YAML generation in the kubernetes/release repository.

Fixes #46426

/kind feature /area release-eng /sig release

[netlify[bot]]

✅ Pull request preview available for checking

Built without sensitive environment variables

Name	Link
🔨 Latest commit	61a8cadcffdba9a8cc9ea7bf6bd54b21c154d702
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-io-main-staging/deploys/6989d73633ac670008398ba5
😎 Deploy Preview	https://deploy-preview-54041--kubernetes-io-main-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[lmktfy]

I can already offer part feedback.

For practical use, the releases.yaml file (which is the single source of truth) needs to be automatically generated and updated.

It's good not to couple too much automation. Even if the release team use a manual process to update those YAML files, the improvements in this PR provide value. So, we shouldn't feel that this PR needs to wait for other parts to be fully automated.

[kfess]

Thank you for the quick feedback.

I understand the main concern is about data sourcing. In this PR, I thought using a YAML file as a single source of truth would make things clearer, but I didn't fully consider the maintenance burden it would place on the release team.

As a next step, I'll investigate how much can be achieved without creating any new /data files, by using the content adapter to pull from existing sources: schedule.yaml, feature gate shortcode data, version information that can be inferred, GitHub Releases API, and other information extractable from the website.

I haven't tried it yet, so I can't say for sure. The implementation on the website side may become more complex, but I have a feeling it's doable.

Please let me know if I'm missing something.

[lmktfy]

In this PR, I thought using a YAML file as a single source of truth would make things clearer, but I didn't fully consider the maintenance burden it would place on the release team.

As a next step, I'll investigate how much can be achieved without creating any new /data files, by using the content adapter to pull from existing sources: schedule.yaml, feature gate shortcode data, version information that can be inferred, GitHub Releases API, and other information extractable from the website.

That's also a good approach in terms of incremental delivery. In other words, even if we were sure that we wanted one YAML file as a source of truth, I would still get there in stages. "Big bang" PRs are a lot harder to review and, as a result, they can languish unmerged for longer than anyone would like.

[kfess]

I have simplified the implementation to include only basic version information. The primary data sources are eol.yaml and schedule.yaml. I'd appreciate your feedback on this approach.

[lmktfy]

https://deploy-preview-54041--kubernetes-io-main-staging.netlify.app/releases/archive/1.35/ looks useful to me.

How about if the URL were https://deploy-preview-54041--kubernetes-io-main-staging.netlify.app/releases/1.35/ – and eventually https://k8s.io/releases/1.35/ - though?

I think it's important not to imply that release v1.35 / the most recent release is archived. If we don't manage that last, I expect a thin but continuing trickle of issues from people who think it needs fixing.

---

I think we could omit the releases from the left hand navigation. Can you see how?

---

This is a good foundation. The thing that I would add next is that for each supported release (and only for supported releases), we link to the download page:

• https://kubernetes.io/releases/download/
• https://v1-34.docs.kubernetes.io/releases/download/
• https://v1-33.docs.kubernetes.io/releases/download/

etc

[Caesarsage]

This look good,

It might be clearer to name this folder releases instead of archive release, since some of the release series listed are still supported and not fully archived.

It may also be helpful to link the supported release page to its corresponding versioned Kubernetes documentation (for example, https://v1-31.docs.kubernetes.io/docs).

[kfess]

@lmktfy @Caesarsage

Thank you for the feedback. I've also made a few changes:

• Hidden these pages from the sidebar by adding toc_hide to params (Is this approach look correct?)
• Moved _content.gotmpl so the URL become /releases/1.35/ instead of /releases/archive/1.35/
• fixed text "Release" issue

I have two questions. Since these pages won't be in the sidebar, how do users access these release pages? Should there be an index page that lists all releases or anything else? Also download links - understood, I can work on that too! Do you think it makes sense to include it in this PR, or would you prefer I split it into a separate one? (If I split it, I think we shouldn't close the original issue yet since there's still quite a bit of work remaining.)

[lmktfy]

Since these pages won't be in the sidebar, how do users access these release pages?

https://kubernetes.io/releases/ already generates info about supported releases. Let's adapt that - ideally a small change and not a big rethink.

I suggest lightly tweaking the existing layout, to put less detail in https://kubernetes.io/releases/ and then hyperlink to the specific release pages. For example, replace "Complete 1.35 Schedule and Changelog" with a click through to the 1.35 minor release page.

To help people find (the pages for) releases that are no longer supported, we need a different change. I personally would use either a <details> element or something that works like one. It is OK for the details element to be initially collapsed.

---

I don't yet know if we would merge the first PR or leave it to become the first commit(s) of a larger PR.

[kfess]

I've added links to the individual release pages from /releases/ for supported versions. I haven't replaced "Schedule and Changelog" yet because that content isn't on the detail pages yet.

I added an EOL releases section with <details> using / modifying the existing shortcode, and added links to individual EOL release pages. For consistency, we might want to add similar links to the supported / maintenance release tables as well.

Also included download page links for supported releases.

Let me know if this looks good.

preview: https://deploy-preview-54041--kubernetes-io-main-staging.netlify.app/releases/

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: e65509fc1f267667dccae7503f1d791f25a21181

[lmktfy]

/area web-development

[lmktfy]

This is a draft PR to gather feedback on a Content Adapter-based release page.

I think it's now reviewable.

[lmktfy]

I also suggest: squash this into 1 or 2 commits, at this point. If you add more changes to this PR, then they will build on the good foundation that you have already prepared.

[reylejano]

I also suggest: squash this into 1 or 2 commits, at this point. If you add more changes to this PR, then they will build on the good foundation that you have already prepared.

I agree with squashing commits Please see https://kubernetes.io/docs/contribute/new-content/open-a-pr/#squashing-commits

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please ask for approval from lmktfy. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS
• content/en/releases/OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[kfess]

I'll wait for your review on the latest updates, and if they look good, I'll squash the commits as you suggested.

After that, I'm thinking of adding related links (CHANGELOG and GitHub tag) as a follow-up commit on top of the squashed foundation. These seem straightforward to include. Does that sound reasonable?

preview: https://deploy-preview-54041--kubernetes-io-main-staging.netlify.app/releases/

[kfess]

I have squashed all commits for the release page content adapter feature. I would appreciate it if you could take a look when you have time.

Preview: https://deploy-preview-54041--kubernetes-io-main-staging.netlify.app/releases/

[lmktfy]

/lgtm

I would like SIG Release to have the chance to object to this – I already called out this PR on Slack.

---

I won't add a merge hold label on this PR, but I do suggest not merging it until 2026-02-13 or SIG Release confirm they are happy, which ever comes sooner. If an approver wants to approve earlier, you can—use judgement. You can just approve; you can check in with SIG Release folks; you can hold-and-approve; you can ask a SIG Docs tech lead for a second / third opinion. Your call.

If anyone does add a hold, please explain under what conditions it's OK to unhold the PR.

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: d4a76834bd9ad71e9b1371e11d863e5bb8390870