Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"version" should not be used for the manifest format version #110

Closed
stuartpb opened this issue Aug 14, 2015 · 8 comments
Closed

"version" should not be used for the manifest format version #110

stuartpb opened this issue Aug 14, 2015 · 8 comments
Assignees

Comments

@stuartpb
Copy link

I think "version" should be reserved for future expansion and/or metadata extensions by the environment, not used for the manifest version the JSON document complies with. That should be specified with a key like Chrome's manifest_version.

@crosbymichael
Copy link
Member

SGTM

@wking
Copy link
Contributor

wking commented Aug 21, 2015

On Fri, Aug 14, 2015 at 03:51:45PM -0700, Stuart P. Bentley wrote:

I think "version" should be reserved for future expansion and/or
metadata extensions by the environment…

I'm not sure what else would go here, but if we want to avoid claiming
‘version’, I'd suggest ‘ocsVersion’, ‘OCSVersion’, or
‘openContainerSpecificationVersion’. The other spec tags are all
mixedCase, so I'd avoid underscores or hyphens. And if we're
namespacing to distinguish between multiple versioned entities, the
special thing about this version entry is that it references this
Open Container Specification 1.

@jonboulle
Copy link
Contributor

FWIW we went through this exact conversation a very long time ago in appc
land and settled on "acVersion". The nice part about this (vs. the more
generic manifest_version) is it also effectively doubles as a magic header
for identifying some generic JSON object as an ocSomething

On Fri, Aug 21, 2015 at 3:03 PM, W. Trevor King notifications@github.com
wrote:

On Fri, Aug 14, 2015 at 03:51:45PM -0700, Stuart P. Bentley wrote:

I think "version" should be reserved for future expansion and/or
metadata extensions by the environment…

I'm not sure what else would go here, but if we want to avoid claiming
‘version’, I'd suggest ‘ocsVersion’, ‘OCSVersion’, or
‘openContainerSpecificationVersion’. The other spec tags are all
mixedCase, so I'd avoid underscores or hyphens. And if we're
namespacing to distinguish between multiple versioned entities, the
special thing about this version entry is that it references this
Open Container Specification 1.


Reply to this email directly or view it on GitHub
#110 (comment)
.

@wking
Copy link
Contributor

wking commented Aug 21, 2015

On Fri, Aug 21, 2015 at 03:12:58PM -0700, Jonathan Boulle wrote:

The nice part about this (vs. the more generic manifest_version) is
it also effectively doubles as a magic header for identifying some
generic JSON object as an ocSomething

config.json is also not a manifest ;). And I prefer ‘ocs’ as a prefix
to just ‘oc’, since I think we want to leave room for additional OCI
specs in the future 1.

@wking
Copy link
Contributor

wking commented Aug 21, 2015

On Fri, Aug 14, 2015 at 03:51:45PM -0700, Stuart P. Bentley wrote:

I think "version" should be reserved for future expansion…

Thinking this over some more, if we do want to namespace our versions,
it might be better to nest a map under ‘version’:

"version": {
"openContainerSpecification": "0.1.0",

}

(or: "ocs": "0.1.0").

That avoids polluting the root JSON namespace with a bunch of
version-related tags. Either way, this “multiple versions” approach
gets us back towards something like the “feature tags” approach I
floated in #15, although there I was suggesting we tag sections of
this spec, and here we're talking about versioning other things
outside of this spec.

Again, I'm still fine keeping this as ‘version’ until we see a
specific example of a non-OCS version that folks want to include in
this OCS config.

@vbatts
Copy link
Member

vbatts commented Jan 13, 2016

could be related to #108, as a bundle author may have more than one way to indicate their version (e.g. git hash, build ID, semver, etc) and it would be tedious to continually add fields for any/all of them. But I agree that this could be more cleanly something like spec_version

vbatts added a commit to vbatts/oci-runtime-spec that referenced this issue Jan 13, 2016
opencontainers#110

Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
@wking
Copy link
Contributor

wking commented Jan 13, 2016

On Wed, Jan 13, 2016 at 03:07:08PM -0800, Vincent Batts wrote:

could be related to #108, as a bundle author may have more than one
way to indicate their version (e.g. git hash, build ID, semver,
etc) and it would be tedious to continually add fields for any/all
of them. But I agree that this could be more cleanly something like
spec_version

In the thread behind #108, I suggest following #188 and using
“annotations” if we want to bless a config.json entry for non-runtime
bundle-author content and that we also allow arbitrary bundle content.
With either of those approaches, I don't see a need for a more
specific label here (and ‘spec_version’ doesn't sound much more
specific anyway ;). But if we want to use a version name that more
clearly maps to this specification (e.g. ocsVersion or
openContainerSpecificationVersion 2), that's fine with me.

 Subject: Re: Labels and extension meta data in containers #108
 Date: Wed, 30 Dec 2015 20:54:37 -0800
 Message-ID: <20151231045437.GA6362@odin.tremily.us>

vbatts added a commit to vbatts/oci-runtime-spec that referenced this issue Jan 14, 2016
opencontainers#110

Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
vbatts added a commit to vbatts/oci-runtime-spec that referenced this issue Jan 15, 2016
opencontainers#110

Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
@hqhq
Copy link
Contributor

hqhq commented Jan 18, 2016

Close in favor of #309

@hqhq hqhq closed this as completed Jan 18, 2016
Mashimiao pushed a commit to Mashimiao/specs that referenced this issue Aug 19, 2016
opencontainers#110

Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants