Improve version selector & rename "master" to "latest"

[thesuperzapper]

In the top right of the website, we have a "version selector" that lets you view archived versions of the docs from past releases, however, the current presentation is confusing to users.

New users expect that they should browse the site on the 1.9 branch for information about 1.9 (when in reality they should browse the master branch because we are always updating it).

In reality, we treat these historical snapshot versions as "snapshot archives" and don't go back to update them with content from master.

This PR makes the following changes to the version menu:

• Renamed the button which you click to expand the menu:
  • For example, in this PR its "Latest", but in the v1.0-branch snapshot it would be "Archive: 1.0"
• prepended Archive: to each version label
• removes versions older than 0.6 from the dropdown

Screenshots

OLD

NEW

[google-oss-prow]

[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 assign james-jwu for approval. For more information see the Kubernetes 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

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

[thesuperzapper]

@andreyvelich I have updated all the other PRs with the following changes:

1. Remove the "Archive: " prefix from the "versions" menu that I added before
2. Update the root OWNERS to align with the current master (KSC members)
3. Updated the "version banner" to look like this:

[thesuperzapper]

We now need someone with GitHub org admin manually merge the following PRs:

• A manual merge is needed because the old OWNERs are not active anymore.
  • WARNING: please remember to use SQUASH merge!
• Improve archived_version banner for v0.2-branch #3869
• Improve archived_version banner for v0.3-branch #3868
• Remove Archive: version dropdown prefix from v0.4-branch #3867
• Block web crawlers on v0.5-branch #3850
• Block web crawlers on v0.6-branch #3851
• Block web crawlers on v0.7-branch #3852
• Block web crawlers on v1.0-branch #3853
• Block web crawlers on v1.1-branch #3854
• Block web crawlers on v1.2-branch #3855
• Block web crawlers on v1.3-branch #3856
• Block web crawlers on v1.4-branch #3857
• Block web crawlers on v1.5-branch #3858
• Block web crawlers on v1.6-branch #3859
• Block web crawlers on v1.7-branch #3860
• Block web crawlers on v1.8-branch #3861
• Block web crawlers on v1.9-branch #3862

[thesuperzapper]

@james-jwu or @zijianjoy can you please update these DNS records, as they don't point to our modern Netlify, so will not be updated otherwise:

1. v0-2.kubeflow.org:
   • OLD CNAME: eager-nobel-1708cf.netlify.com
   • NEW CNAME: v0-2-branch--competent-brattain-de2d6d.netlify.app
2. v0-3.kubeflow.org:
   • OLD CNAME: competent-jones-a15cc2.netlify.com
   • NEW CNAME: v0-3-branch--competent-brattain-de2d6d.netlify.app
3. v0-4.kubeflow.org:
   • OLD CNAME: infallible-hermann-cb44b2.netlify.com
   • NEW CNAME: v0-4-branch--competent-brattain-de2d6d.netlify.app
4. v0-5.kubeflow.org:
   • OLD CNAME: practical-neumann-e70801.netlify.com
   • NEW CNAME: v0-5-branch--competent-brattain-de2d6d.netlify.app
5. v0-6.kubeflow.org:
   • OLD CNAME: v0-6-branch--competent-brattain-de2d6d.netlify.com
   • NEW CNAME: v0-6-branch--competent-brattain-de2d6d.netlify.app
6. v0-7.kubeflow.org:
   • OLD CNAME: v0-7-branch--competent-brattain-de2d6d.netlify.com
   • NEW CNAME: v0-7-branch--competent-brattain-de2d6d.netlify.app

[andreyvelich]

@kubeflow/kubeflow-steering-committee @kubeflow/wg-pipeline-leads @kubeflow/wg-data-leads @kubeflow/wg-training-leads @kubeflow/wg-notebooks-leads @kubeflow/wg-manifests-leads Can you give +1 on the banner that @thesuperzapper proposed for the old docs ?

If that looks good to you, we can start merging the PRs on the old website branches.

[andreyvelich]

@thesuperzapper Only one comment from me, that I don't think that we should add yellow banner on the 1.9 documentation, since it is the latest stable release.
As you can see, the Kubernetes doesn't have this banner on the latest v1.31 version:

• https://kubernetes.io/docs/concepts/workloads/controllers/job/
• https://v1-30.docs.kubernetes.io/docs/concepts/workloads/controllers/job/

WDYT @thesuperzapper ?

[thesuperzapper]

@thesuperzapper Only one comment from me, that I don't think that we should add yellow banner on the 1.9 documentation, since it is the latest stable release. As you can see, the Kubernetes doesn't have this banner on the latest v1.31 version:

• https://kubernetes.io/docs/concepts/workloads/controllers/job/
• https://v1-30.docs.kubernetes.io/docs/concepts/workloads/controllers/job/

WDYT @thesuperzapper ?

@andreyvelich on the Kubernetes docs, "1.31" is actually a link to kubernetes.io, which is their master branch.

The problem is that we have already cut a v1.9-branch for "1.9", so it really is a "snapshot of the docs at the time of the 1.9 release". If we don't have the warning, people won't realize they are not viewing the updated version of the 1.9 docs (which live on master).

In the future, I think we should hold off on cutting the 1.10 branch until just before we start merging docs for the 1.11 release. To resolve the current situation, we have two options:

1. OPTION 1: Keep the current v1.9-branch and retain the warning header.
2. OPTION 2: Delete the current v1.9-branch and only re-create it once we start the 1.10 release process

[juliusvonkohout]

"While that is nice in theory, it's a separate discussion to this as we currently don't support anything but 1.9.0." yes there is just not much capacity beyond that. This might change if someone volunteers. We only fix critical things that are easy to fix, so in practice it was around 1 Year for 1.8/1.8.1 and with 1.9.1 released 1.8.1 will be EOL for most developers. For longer support you probably need distributions, consultants etc.

I like the term master more than latest, but I am also in favour of pushing for the master/latest version being shown by default and marking everything 2 releases away, so 1.8.1 and older as archived, snapshot, xxx End of Life or so.

[tarilabs]

/lgtm

I can see the dropdown and the version banner in the linked PRs, thank you!

[andreyvelich]

As we discussed during today's community call, we can manually squash + merge all PRs to disable indexing on old branches.
We should just have followup discussion for the PR on 1.9 branch.
@johnugeorge @terrytangyuan @james-jwu @jbottum Can you help to manually squash + merge these PRs if you are agree with the banner:
#3869
#3868
#3867
#3850
#3851
#3852
#3853
#3854
#3855
#3856
#3857
#3858
#3859
#3860
#3861

[james-jwu]

I've done the squash + merge.

[zijianjoy]

Both the DNS configuration and the Kubeflow website hosting on Netlify are transferred to CNCF. Would you like to make a request to CNCF by submitting a service deck ticket? https://cncfservicedesk.atlassian.net/servicedesk/customer/portals

[jbottum]

it seems like there are several activities in this PR. I am a -1 on the initial proposal to change from master, 1.9. i.e. I am -1 on latest and archive proposal.

[jbottum]

+1 for master rather than latest