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

[stuartpb]

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]

SGTM

[wking]

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]

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 [email protected]
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]

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]

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]

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

[wking]

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: <[email protected]>

[hqhq]

Close in favor of #309