Publish docs for historical Kubernetes releases

[Mamonaminyar]

In slack, @sftim, you mentioned wanting to surface all of the previous k8s documentation versions. I like this idea.

[edit] You mentioned previous versions back to v1.0. I assume that still means about 20 versions?

serve all documentation from one site with perhaps a prefix: /docs/v1.18/home/ and /docs/v1.19/home/ etc

Thinking about these two things together: this could greatly increase the size of the site.

I've been looking at this style of versioning for etcd - and I think that it works well for small to medium sized sites, at least the way I've seen it set up using folders (there may be other ways of achieving this organization).

The Kubernetes site is much bigger than the sites I've seen managing versioning with a folder system though.

If we were to place all ~20 previous versions each in their own folder under /content, I think we may start to see some deploy performance issues.

With all languages in, I think the Docs section of the Kubernetes website is ~6500 files and ~65 MB (current version, older versions would likely be smaller). If we include all ~20 versions in one repo, we'll inflate that to ~1.3 GB.

[edit] I suppose they're all already in one repo. Currently we're using branches to version, and git does some very nifty space saving magic for us. File size may not be the most important factor here.

I've seen the deploy log for v1.16, and it takes about 7 minutes to do the full deploy. Building the sites currently takes about 0.3 minutes of that (~23000 ms). If we have to build all 20 versions each time we deploy (or deploy preview), we may be adding about 6 minutes to the overall deploy (Rounding down because older versions may be smaller, and I'm not very familiar with Hugo & Netlify yet, they may do some clever things to speed this up).

This would be fairly easy to test though - we could just copy the current /docs folder 20x over and do a draft PR to see how long it takes to deploy. There could be some clever de-duplication we could look into as well to help mitigate some of these concerns.

Originally posted by @nate-double-u in #23518

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[stmcginnis]

/retitle Publish docs for historical Kubernetes releases

[lmktfy]

I imagine that the ask is to [find an effective way to] make a much broader range of docs versions available.

It might need significant donations of either money or time to make it happen.

[lmktfy]

/sig docs
/kind feature
/area web-development

If we decide that this is a duplicate of issue #23518, we can close this one. Right now I think the request is similar but different.

[lmktfy]

Before we do accept this, is someone (doesn't have to be @Mamonaminyar) want to outline roughly how we'll do it?

(if we're not sure, we could split it - first, a spike or investigation to see if it's possible; second, implement the thing that the investigation shows we ought to do)