search

opencontainers / artifacts

OCI Artifacts
https://opencontainers.org
Apache License 2.0
224 stars 54 forks source link

Releases Please #23

Closed mattfarina closed 1 year ago

mattfarina commented 4 years ago

OCI specs appear to have releases (e.g., image spec and distribution spec). These are great for consumers of the specs because we know where they stand. If something is a feature addition, breaking change, and so forth. And, if someone implements a spec we know by the version when things break.

Can we get released versions of artifacts?

Without releases I can't tell its stability. Is this an experiment that might easily change or something that's stable with staying power?

mikebrow commented 4 years ago

It's not a spec.. it's going to be a running reference with guidance... The samples will define the dependencies, such as versions of the image and distribution spec.

mikebrow commented 4 years ago

Can we get released versions of artifacts?

I would expect each artifact type to have versioning, releases, ...

https://github.com/opencontainers/artifacts/blob/master/artifact-authors.md#defining-a-unique-artifact-type

mikebrow commented 4 years ago

Without releases I can't tell its stability. Is this an experiment that might easily change or something that's stable with staying power?

See here: https://github.com/opencontainers/tob/blob/master/proposals/artifacts.md#versioning--roadmap

We would have to go back to the tob and request a change in scope for the project to add a specification w/versioning.

Hopefully some "optional" tests can be added to distribution for particular artifact samples. Maybe in a subsequent release of images / distribution it (requirements) can be more formal.

Thoughts?

dmcgowan commented 4 years ago

Without releases I can't tell its stability. Is this an experiment that might easily change or something that's stable with staying power?

I would like to better understand what stability here means. We are trying to figure out how these will be consumed by end users so we can figure out what the deliverable is. How do you expect to consume this repository?

SteveLasker commented 4 years ago

I believe the questions are: Q: if a group creates an artifact, (aka helm), with a specific config.mediaType, how can they know they won't get broken in the future? A: This was the delay in identifying the format of artifact mediaTypes. With that complete, and merged, that question should be closed.

Q: how does an artifact author claim ownership of a unique mediaType? A: this was the other delay in researching the IANA registration process. The current artifact-authors.md describes: Registering Unique Types with IANA to resolve this concern. We will have a new updated version of Optional: Publishing the Artifact Type that will define the publishing process. However, this doesn't block an artifact author from defining their type, or owning their unique config.mediaType. It just means there's no definition of a "clearing house" of types, yet. This is an opportunity to do better, and part of the TOB commitment, but not a blocker.

Q: It's great to have a merged document, but what stops someone from changing it? A: This is where the versioning question likely has the most relevance. There's nothing stopping someone from making a breaking change to a spec either, there's just a process. A specific published/versioned spec shouldn't take a breaking change. There's a process of defining a new version that defines the change in behavior. The artifacts repo does not have this process defined.

So, the question could be: Why not have a versioned artifacts spec, to formalize this commitment?

mikebrow commented 1 year ago

@mattfarina old issue here, mission for this is moving to the image and distribution spec where artifacts support is scheduled to be released with the image and distribution 1.1 specs. Cheers!