Change:
| ----------------------------------- | --------------------- | -------- | ---- | | `app.kubernetes.io/name`            | The name of the application | `mysql` | string | | `app.kubernetes.io/instance`        | A unique name identifying the instance of an application | `mysql-abcxzy` | string | <del> | `app.kubernetes.io/version`         | The current version of the application (e.g., a semantic version, revision hash, etc.) | `5.7.21` | string | </del> <ins> | `app.kubernetes.io/version`         | The current version of the application (e.g., a [SemVer 1.0](https://semver.org/spec/v1.0.0.html), revision hash, etc.) | `5.7.21` | string | </ins> | `app.kubernetes.io/component`       | The component within the architecture | `database` | string | | `app.kubernetes.io/part-of`         | The name of a higher level application this one is part of | `wordpress` | string | | `app.kubernetes.io/managed-by`      | The tool being used to manage the operation of an application | `helm` | string |

Discussion:
The page recommends setting the label. One of the suggested values is a semver. The problem with that recommendation is that there are plenty of fully compliant semvers that are incompatible with the restrictions that k8s put on the . Including the build number, for example, will cause a runtime error:
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 label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/retitle Recommended Labels page suggests using SemVer when only a subset of semvers are valid A plausible fix would be to specify the version of SemVer - as I understand it, all 1.x SemVers are valid. /language en
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen /lifecycle frozen /priority backlog
Reopened this issue. <detailsIn response to : /reopen /lifecycle frozen /priority backlog Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/kind bug /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /kind bug /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository.

</details
I guess that another option is to add notes after the table that should contain something similar to
If we can agree with text change, I can work on this
That's quite vague still, and doesn't really help in understand what is allowed. Would it make sense to mention "Semantic Versioning 1.0.0"?
I think it would. We're then explicitly declaring a version of, uh, SemVer that we can be compatible with, following the rules of that version of SemVer.
you are welcome to edit the issue description with that recommended fix, or to include a link to
Ok so we want to change the description in the table to If we agree with such wording, I can create a PR with it.
As a project, let's recommend using SemVer 1.0 We can explain that if people want to use another version scheme, they have options: use your own annotation (custom key) use different label, which means using a custom key for that I wonder if actually we should be recommending use of as an annotation, not a label. However let's not do that yet; for now, let's fix the issue where we're not specifying a suitable SemVer version, and save the bigger discussion for another time.
/assign
PR to get things started: I'm not sure how far/how we wanted to go about this - recommend using SemVer 1.0 - do we mean more so than revision, hash, etc? In which case re-word the whole line from: to Then for the explanation on custom keys, add to the bottom of the table as a footnote or something similar?
Also see