Open gallettilance opened 2 years ago
I'm not sure it makes sense to do this for the entire version string. All kubernetes resource names have a set of character and length restrictions that make them incompatible with semver strings. See:
https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Compare that to the semver spec, for example build metadata which includes +
characters: https://semver.org/#spec-item-10 and there's already an obvious incompatibility.
In general, the convention operators have been following has been:
$operatorname.v.$majorversion.$minorversion.$patchversion
I think it could make sense to parse the csv metadata.name
and pull the major minor and patch versions, and ensure that those match, but this is still mostly for the purpose of UX and information, so I don't think we should restrict the spec.version of csvs from the current allowable values -- today that looks like anything that conforms to the semver spec.
It shows for me that what we can do here is check if the v.$majorversion.$minorversion.$patchversion
when present matches with the CSV.spec version and provides warnings when not. That would fit well in the Good Practices Validator when we check if the Operator Bundle name follows the convention $operatorname.v.$majorversion.$minorversion.$patchversion
.
Note that the PR: https://github.com/operator-framework/api/pull/238 shows block this one.
@ryantking wdyt? Could you give us a hand with this one? c/c @gallettilance
validation that exists today in the operatorhub test suite only checks that the csv name is "name + a version" not "name + the version field" https://github.com/operator-framework/api/blob/a7ebc81c9577a300814448a901edae74c6e6e44e/pkg/validation/internal/operatorhub.go#L247
This means teams can release
myoperator.v.1.0.0
withversion: 1.0.1
which should not pass validation.