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

[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

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This pull request has been automatically closed because it has not had recent activity.You can reopen the PR if you want.

[thesuperzapper]

We still need to decide what to do here regarding "master", but the "archived message" update from this PR is still important for when we branch off future release branches (and set the archived flag to true).

/reopen

[google-oss-prow]

@thesuperzapper: Reopened this PR.

In response to this:

We still need to decide what to do here regarding "master", but the "archived message" update from this PR is still important for when we branch off future release branches (and set the archived flag to true).

/reopen

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/test-infra repository.

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

[juliusvonkohout]

+1 for master rather than latest

This is also my opinion.

[varodrig]

My opinion is to not use master,
as github renamed master to main https://github.com/github/renaming why it was renamed https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main even thought this in terms of branching, I prefer not to use master.

Is there an option to do something like kubernetes does for their versioning? only showing the release numbers?

https://kubernetes.io/releases/

[thesuperzapper]

closing in favor of one that just updates the norobots meta tag template: #4119

/close

[google-oss-prow]

@thesuperzapper: Closed this PR.

In response to this:

closing in favor of one that just updates the norobots meta tag template: #4119

/close

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/test-infra repository.