Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"portability" would need to be explicitly defined for discussing this PR further
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I have in mind "portability" between 1.0 and 1.1 registries, so perhaps "backwards compatibility with OCI 1.0" is a better phrase? We could link to a section of image manifest describing its use for packaging non-container-image content.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with that messaging change. It should be OK for an implementation to decide its own destiny if they've already adopted OCI 1.0 image spec and they want to phase it out at a major version change, their compatibility story is their own business.
The same applies for all future versions, and in fact, all future image-spec types!
How about this in spec.md or in all manifest types?
@sudo-bmitch does that address your objection about non-deterministic behavior? I should be able to look at a tool like
[email protected]and its command line arguments and know what it will produce. Tools that are clever and try to automatically fall back will end up surprising users.And understanding @sudo-bmitch's concern, I'll also close this issue:
I don't think it's a good idea to specify fallback behavior any longer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sudo-bmitch re:
Such as a user intentionally upgrading to a new major version, i.e.: OCI client Foobarctl says "with major version v3, we default to artifact now and will fail on pushing to an OCI 1.0 registry. Opt out of this behavior by passing
--oci-spec=v1.0"?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After the conversations yesterday, some kind of verbiage could be useful. Let's steer to something hand-wavy, but maybe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the wording that @vbatts provides, with the addition that I'd like to include a "SHOULD NOT use" suggestion in there to stress our desire for portability.