Remove misleading "must" in ref.name requirements
#1196
Conversation
tianon
requested review from
jonjohnsonjr,
stevvooe,
sudo-bmitch,
sajayantony and
cyphar
as code owners
|
Perhaps this should be SHOULD instead to match the earlier requirement? I'm happy to update. |
|
(however, to be explicit, I do think using "must" here is a bug and we should fix it to either MUST or SHOULD so the intent is 100% clear and no longer ambiguous -- MUST is more consistent with the language used, but SHOULD is more consistent with the rest of the annotation's stated limitations) |
There was a problem hiding this comment.
This makes me really want to define a reference somewhere in OCI, and then have this as a pointer to that definition. Given that the previous line says "SHOULD", I think converting this to a hard MUST is incompatible with the previous line and could break anyone that is treating themselves as an exception to the SHOULD.
I'd lean towards removing "must" completely, and just say "A valid reference matches the following grammar". That would straddle the "here's what you should do" with the hint of "don't be surprised if there are implementations doing invalid stuff". I'd also accept changing this from "must" to "SHOULD".
Signed-off-by: Tianon Gravi <[email protected]>
tianon
changed the title
ref.name requirementsref.name requirements
|
Sure, no strong argument here -- updated! |
|
(CI failure is unrelated 🙃) |
This comment was marked as spam.
This comment was marked as spam.
See b692dee (#695) for where this was originally added (making clear this was the original intent).IMO it slightly conflicts with the bullet point above it being simply SHOULD, but it has been part of the spec since v1.0 (and in a disagreement between MUST and SHOULD, the stronger constraint wins and that's MUST).Updated: #1196 (review)