Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing leading 'v' for start command on new version available #8114

Closed
BobyMCbobs opened this issue May 13, 2020 · 2 comments · Fixed by #8118
Closed

Missing leading 'v' for start command on new version available #8114

BobyMCbobs opened this issue May 13, 2020 · 2 comments · Fixed by #8118
Labels
kind/bug Categorizes issue or PR as related to a bug. kind/ux priority/backlog Higher priority than priority/awaiting-more-evidence.

Comments

@BobyMCbobs
Copy link
Member

Steps to reproduce the issue:

  1. minikube start on 1.10.0
  2. minikube start on 1.10.1 suggests Kubernetes 1.18.2 is now available. If you would like to upgrade, specify: --kubernetes-version=1.18.2
  3. minikube start --kubernetes-version=1.18.2 fails with the final line as Suggestion: Check that your --kubernetes-version has a leading 'v'. For example: 'v1.1.14'

Resolution:
The message about updating the minikube cluster should be something like

Kubernetes 1.18.2 is now available. If you would like to upgrade, specify: --kubernetes-version=v1.18.2

This could either be how the strings are printed, or the actual version itself.

out.T(out.New, "Kubernetes {{.new}} is now available. If you would like to upgrade, specify: --kubernetes-version={{.new}}", out.V{"new": defaultVersion})

References:

@afbjorklund
Copy link
Collaborator

@BobyMCbobs : thanks for reporting, the variable should be split into two (one for user, one for machine). This "silent v" in versioning is very annoying, and comes originally from a git limitation.

The reason for the preceding 'v' is historical. Older SCCS (cvs,rcs) could not distinguish between a tag identifier and a revision number. Tag identifiers were restricted to not begin with a numeric value so that revision numbers could be detected.

@afbjorklund afbjorklund added kind/bug Categorizes issue or PR as related to a bug. priority/backlog Higher priority than priority/awaiting-more-evidence. kind/ux labels May 13, 2020
@afbjorklund
Copy link
Collaborator

Typically, we spent more time on changing the emoji than verifying if it actually worked :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. kind/ux priority/backlog Higher priority than priority/awaiting-more-evidence.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants