Add --version to cmd to show version information

[coolljt0725]

Signed-off-by: Lei Jitang [email protected]
Users should have a way to know the spec version and code commit of
the image-tool

[lei@fedora image-tools]$ ./oci-create-runtime-bundle --version
commit: 721ba581955c2b8ce1184d7492ed5e3f5ba3e1d4
spec: 0.3.0-dev
[lei@fedora image-tools]$ ./oci-image-validate --version
commit: 721ba581955c2b8ce1184d7492ed5e3f5ba3e1d4
spec: 0.3.0-dev
[lei@fedora image-tools]$ ./oci-unpack --version
commit: 721ba581955c2b8ce1184d7492ed5e3f5ba3e1d4
spec: 0.3.0-dev

[runcom]

yeah, git commit will be useful also to print some debug while validating images maybe - we'll need opencontainers/image-spec#307 also somehow

[wking]

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:

specs: 0.4.0

now. Once opencontainers/image-spec#289 lands and we bump to the new tag, we should be showing:

specs: 0.5.0

Once 1.0 is cut we should show:

specs: 1.0.0

Once 1.1 is cut we should show our position in the 1.x series:

specs: 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:

specs: 1.1.0, 2.0.0

And if the caller explicitly asked for the version information with --version, I think we should be printing it to stdout instead of stderr.

[coolljt0725]

@wking

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:

I think this is hard. It's not only the v1 package, the spec define the image layout, how we validate the image, how we unpack the layer... etc, this could be differ from version to version. the tool is a implementation of the spec at some point, the

specs: 0.4.0

means the tool is developed based on the v0.4.0 spec.
After 1.0, I agree to show the supported versions but the tool need to do some backward compatibility thing.

And if the caller explicitly asked for the version information with --version, I think we should be printing it to stdout instead of stderr.

This is a mistake, will fixed.

[wking]

On Sun, Sep 18, 2016 at 11:27:36PM -0700, Lei Jitang wrote:

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:

I think this is hard. It's not only the v1 package, the spec
define the image layout, how we validate the image, how we unpack
the layer... etc, this could be differ from version to version.

And where there are backwards-incompatible changes, media types should
be bumped to represent that. So the tooling might need to different
unpacking helpers (e.g. one for 1.2 and another for 2.0), but the 1.2
unpacker would be able to handle 1.0, 1.1, and 1.2. I think we should
include minors in either our media types
(e.g. application/vnd.oci.image.manifest.v1.0+json) or in a version
field inside the JSON (where runtime-spec uses ociVersion 1) so the
tooling that only handles 1.x through 1.2 can detect and error out if
it gets a 1.3 manifest (or whatever).

[vbatts]

i like this as a first step. I do not expect the tool to keep a matrix of compatibility support, at least not in the initial stages. And the addition of project URL can be added later.

LGTM