documentation for start command is from the future

[FlorinAndrei]

This page:

https://minikube.sigs.k8s.io/docs/commands/start/

Claims this option is available for the start command:

--ha Create Highly Available Multi-Control Plane Cluster with a minimum of three control-plane nodes that will also be marked for work.

That is not true for the current stable version of minikube (1.32.0). It only appears to be true for the current beta (???).

Please reconcile.

[T-Lakshmi]

Hi @FlorinAndrei,

That is not true for the current stable version of minikube (1.32.0). It only appears to be true for the current beta (???).

Yes, you are true. This feature is newly implemented in current beta version of minikube release.

[T-Lakshmi]

--ha Create Highly Available Multi-Control Plane Cluster with a minimum of three control-plane nodes that will also be marked for work.

As minikube documentation includes information about both current stable and beta release types, i think it is recommended that we leave this information as is and add a small note (it is currently available for v1.33.0-beta.0 release).

what do you think @FlorinAndrei ?

[FlorinAndrei]

All other projects I've seen in my years in the industry make sure their main official documentation is for the stable version.

When they do provide documentation for the beta version, it's a separate version of the documentation, and it is very clearly marked as such, and it does not mislead the users into thinking it's the stable branch documentation.

I have no clue why minikube does things differently from the rest of the world.

If you want your users to use the beta code more quickly, then promote it to stable.

[afbjorklund]

It is a bug, the website is carried in the main monorepo and so it is updated whenever git HEAD is...

• Make website documentation versioned  #6921

There is no special promoting of beta releases.

Preferrably it should default to "Latest" release.

[T-Lakshmi]

/kind bug

[afbjorklund]

Last time it was deemed to have too much work to have one documentation site per minikube version:

• Enable version switcher on docs site #5424 (comment)

But it could be possible to have two sites, one for main branch and for the latest release version.

Note that minikube does not have release branches

[FlorinAndrei]

But it could be possible to have two sites, one for main branch and for the latest release version.

If it does not imply that features currently only in beta are also in the latest stable release, then it should be fine. That's all I'm asking. It's the leakage from beta into stable that is not right.

[afbjorklund]

It's the leakage from beta into stable that is not right.

It's not only beta, it is everything that is in the repository.

But I was meaning something like this (for another project):

https://apptainer.org/documentation/

The latest release is labelled latest below. The current development version will be labelled main .

The lack of a stable branch complicates the git, but there is json:

https://github.com/kubernetes/minikube/blob/master/deploy/minikube/releases-v2.json (v1.32.0)

However, I don't even know where the netlify job is configured...

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.