cmd/oci-image-tool/main.go: Add description with supported versions #36
Conversation
|
Maybe we had better to announce in README that image tool support downward compatibility for spec, instead of listing series of versions.
|
|
On Tue, Nov 08, 2016 at 07:59:59PM -0800, xiekeyang wrote:
I don't think we plan on supporting 1.0 forever. I also don't expect
It doesn't seem that confusing to me. Eventually image-spec makes a If, instead, they see: spec: 2.0.0 it's less clear to me what a user with a 1.x image will do. Do they |
|
but it is only the image-spec. This seems confusing. If there are multiple versions covered, it is not different specs per se. |
|
On Tue, Feb 14, 2017 at 05:40:04AM -0800, Vincent Batts wrote:
but it is only the image-spec. This seems confusing. If there are
multiple versions covered, it is not different specs per se.
So “OCI Image Format Specification versions:”?
|
|
:-\ maybe?
On Tue, Feb 14, 2017 at 12:59 PM, W. Trevor King <notifications@github.com>
wrote:
… On Tue, Feb 14, 2017 at 05:40:04AM -0800, Vincent Batts wrote:
> but it is only the image-spec. This seems confusing. If there are
> multiple versions covered, it is not different specs per se.
So “OCI Image Format Specification versions:”?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#36 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEF6VqcApEF_FzBsQCzC5LqRdPQDCDQks5rceuTgaJpZM4KQhWe>
.
|
|
On Tue, Feb 14, 2017 at 01:54:27PM -0800, Vincent Batts wrote:
:-\ maybe?
Or maybe use ‘specs’ (or ‘spec’, or whatever you want), and document
it in the man pages:
-v, --version Print version information and exit. The output format
includes the following fields:
…
specs: A space-delimited list of supported OCI Image Format
Specificiation versions. When multiple versions are supported,
the highest version for each major number will be listed.
…
If you don't have particular wording in mind, I suggest we just pick
something and move on. We can always cycle back around and remove any
remaining ambiguity later, but deciding to only support a single
version at a time seems short-sighted.
|
|
|
|
On Mon, Jul 10, 2017 at 11:34:00PM -0700, Zhou Hao wrote:
`version` option has benn changed, and `spec` is no longer used so
closing this.
It looks like they were dropped in #103, but I don't see any
discussion there about why the ‘spec(s)’ entry was dropped. Perhaps
we should re-open this PR and restore the line? Or add a ‘version’
command that provides more detail than the current [1]? Otherwise
it's not clear to me how a user is supposed to discover what
image-spec version their oci-image-tool build targets, short of
tracking the image-tool commit / version back to GitHub and reading
the source.
[1]: https://github.com/opencontainers/image-tools/blob/144d94513ae640edca038a0b1c3ecc9e28890272/cmd/oci-image-tool/main.go#L34-L36
|
|
@wking I think you can add the |
This shows up in the --help output. I expect image-tools to support a range of image-spec versions, not just a single one. For example, once image-spec cuts 2.0, image-tools should still be able to process 1.x images for some reasonable deprecation period. image-spec is setting us up for that possibility by using the v1 package for the Go types that are likely to change. And SemVer means that if we can unpack a 1.3 image, we can also unpack 1.2, 1.1, and 1.0 images. So I think we want this to be printing: * OCI Image Format Specification: 1.0.0-rc5 now. Once 1.0 is cut we should show: * OCI Image Format Specification: 1.0.0 Once 1.1 is cut we should show our position in the 1.x series: * OCI Image Format Specification: 1.1.0 And then when 2.0 is cut we should show our positions in both the 1.x and 2.x series. If 2.0 happened after 1.1 (without a 1.2, etc.), that would be: * OCI Image Format Specification: 1.1.0, 2.0.0 I see less need to support multiple runtime-spec formats, since they're only used in 'oci-image-tool create ...'. But the approach I used for image-spec ports well to runtime-spec, so I've listed a version for it too. Signed-off-by: W. Trevor King <wking@tremily.us>
wking
changed the title
|
Rebased around #103 with 5157b15 → aad3305, and now output looks like: |
but |
|
@wking restarted CI, seems good. Please rebase your PR |
5 participants
In the --version output.
I expect image-tools to support a range of spec versions, not just a single one. For example, once image-spec cuts 2.0, image-tools should still be able to process 1.x images for some reasonable deprecation period. image-spec is setting us up for that possibility by using the v1 package for the Go types that are likely to change. And SemVer means that if we can unpack a 1.3 image, we can also unpack 1.2, 1.1, and 1.0 images. So I think we want this to be printing, uh:
now. Once we bump our vendored library to catch up with opencontainers/image-spec#354, we should be showing:
Once 1.0 is cut we should show:
Once 1.1 is cut we should show our position in the 1.x series:
And then when 2.0 is cut we should show our positions in both the 1.x and 2.x series. If 2.0 happened after 1.1 (without a 1.2, etc.), that would be:
Spun off from here.