Image Policies should specify if version tags starting with a "v" are valid

[Xjs]

On https://github.com/Masterminds/semver it looks like a tag like v1.2.3 would be a valid SemVer tag under the SemVer ImagePolicy. I would like to see this fact explicitly reflected (or explicitly demented, maybe with a workaround regexp if necessary) on the documentation pages for Flux.

[kingdonb]

It's a bit more complicated than one single answer (all the more reason to have it documented explicitly)

fluxcd/helm-controller#670

I think the answer is no, we don't support it, because it's not in strict semver:
https://semver.org/#is-v123-a-semantic-version

But you may find here or there, it works, because the masterminds library is used. This is not a guarantee. Semver library says optionally support "v" - for Flux purposes, supporting v prefix means adding ambiguity. When an ImageRepository has both tags pushed - v1.0.1 and 1.0.1 which one wins?

For Helm, it definitely is not supported, based on a quick search of issues in the helm-controller repo.

In Image Automation Controller, it seems like it is supported, based on these comments about weak semver validation:
https://github.com/fluxcd/image-automation-controller/blob/799d50569676e1bc1c1b995f4f015e77ff989084/pkg/update/setters.go#L169

In a repo that switches from v-prefixed to non-v-prefixed versions I guess it is still easy enough to tell which one wins, v1.0.1 or 1.0.2, but if there is ambiguity in the tags, then Flux is maybe going to fail to select a latest image.

If you pushed both tags v1.0.1 and 1.0.1 with identical content, it might not matter, but in some cases I'm sure it could matter, and in the worst case (I expect this behavior, haven't tested though) Flux will not select any image when there are multiple image candidates that could be the latest.

When the question comes up, to avoid ambiguity in the answer, I think we always answer that it's not supported because semver.org unambiguously states that the v is not part of the strict semver spec, (but apparently ymmv.)

[kingdonb]

If anyone noticed the flux-e2e guide, I think that's an appropriate place for information like this - I don't have the bandwidth to file a PR for this right now, nor sure where else we could put a note about v prefixes in the docs that it would be easily discoverable.