config: qualify the name of the version field #309

vbatts · 2016-01-13T23:13:16Z

#110

Signed-off-by: Vincent Batts vbatts@hashbangbash.com

vbatts · 2016-01-13T23:13:28Z

Closes #110

tianon · 2016-01-13T23:13:56Z

LGTM

vishh · 2016-01-13T23:17:26Z

LGTM

wking · 2016-01-13T23:25:51Z

config.go

@@ -5,7 +5,7 @@ package specs
 // bundle is packaged for distribution.
 type Spec struct {
 	// Version is the version of the specification that is supported.
-	Version string `json:"version"`
+	Version string `json:"spec_version"`


I'd rather have a more specific name. Presumably the other versioned things were distinguishing from also have specs (and the current JSON pattern is camelCase, not underscores).

mrunalp · 2016-01-14T22:16:06Z

config.md


-* **`version`** (string, required) must be in [SemVer v2.0.0](http://semver.org/spec/v2.0.0.html) format and specifies the version of the OCF specification with which the container bundle complies. The Open Container spec follows semantic versioning and retains forward and backward compatibility within major versions. For example, if an implementation is compliant with version 1.0.1 of the spec, it is compatible with the complete 1.x series. NOTE that there is no guarantee for forward or backward compatibility for version 0.x.
+* **`spec_version`** (string, required) must be in [SemVer v2.0.0](http://semver.org/spec/v2.0.0.html) format and specifies the version of the OpenContainer specification with which the bundle complies.


should be specVersion

i already pushed a change for this. PTAL

On Thu, Jan 14, 2016 at 5:16 PM Mrunal Patel notifications@github.com
wrote:

In config.md
#309 (comment):

-* version (string, required) must be in SemVer v2.0.0 format and specifies the version of the OCF specification with which the container bundle complies. The Open Container spec follows semantic versioning and retains forward and backward compatibility within major versions. For example, if an implementation is compliant with version 1.0.1 of the spec, it is compatible with the complete 1.x series. NOTE that there is no guarantee for forward or backward compatibility for version 0.x.
+* spec_version (string, required) must be in SemVer v2.0.0 format and specifies the version of the OpenContainer specification with which the bundle complies.

should be specVersion

—
Reply to this email directly or view it on GitHub
https://github.com/opencontainers/specs/pull/309/files#r49793850.

On Thu, Jan 14, 2016 at 02:37:10PM -0800, Vincent Batts wrote:

+* spec_version (string, required) must be in SemVer v2.0.0 format and specifies the version of the OpenContainer specification with which the bundle complies.

i already pushed a change for this. PTAL

4df6c3b (the current tip) has specVersion in config.go but
spec_version in config.md (twice). Are we sure we don't want a more
specific name [1,2]?

+1 to more specific name.

On Fri, Jan 15, 2016 at 12:25 AM, W. Trevor King notifications@github.com
wrote:

In config.md
#309 (comment):

-* version (string, required) must be in SemVer v2.0.0 format and specifies the version of the OCF specification with which the container bundle complies. The Open Container spec follows semantic versioning and retains forward and backward compatibility within major versions. For example, if an implementation is compliant with version 1.0.1 of the spec, it is compatible with the complete 1.x series. NOTE that there is no guarantee for forward or backward compatibility for version 0.x.
+* spec_version (string, required) must be in SemVer v2.0.0 format and specifies the version of the OpenContainer specification with which the bundle complies.

On Thu, Jan 14, 2016 at 02:37:10PM -0800, Vincent Batts wrote: > +*
spec_version (string, required) must be in SemVer v2.0.0 format and specifies the version of
the OpenContainer specification with which the bundle complies. i already
pushed a change for this. PTAL
4df6c3b
4df6c3b
(the current tip) has specVersion in config.go but spec_version in
config.md (twice). Are we sure we don't want a more specific name [1,2]?
[1]: #309 (comment)
#309 (comment)
[2]: #110 (comment)
#110 (comment)

—
Reply to this email directly or view it on GitHub
https://github.com/opencontainers/specs/pull/309/files#r49801534.

ociVersion

+1 to ociVersion

Sent from my iPhone

On Jan 15, 2016, at 6:28 AM, Doug Davis notifications@github.com wrote:

In config.md:

-* version (string, required) must be in SemVer v2.0.0 format and specifies the version of the OCF specification with which the container bundle complies. The Open Container spec follows semantic versioning and retains forward and backward compatibility within major versions. For example, if an implementation is compliant with version 1.0.1 of the spec, it is compatible with the complete 1.x series. NOTE that there is no guarantee for forward or backward compatibility for version 0.x.
+* spec_version (string, required) must be in SemVer v2.0.0 format and specifies the version of the OpenContainer specification with which the bundle complies.
ociVersion

—
Reply to this email directly or view it on GitHub.

opencontainers#110 Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>

vbatts · 2016-01-15T15:52:26Z

updated to ociVersion. PTAL

duglin · 2016-01-15T15:54:08Z

+1

tianon · 2016-01-15T16:33:49Z

re-LGTM

wking · 2016-01-15T17:21:16Z

ociVersion is better, but we may end up with multiple OCI specs.
We're calling this spec “Open Container Specifications” 1, so why
not “ocsVersion”?

duglin · 2016-01-15T18:35:32Z

Not to take us down too much of a tangent, but do we have one spec or multiple in this project? If we have multiple then "ocs" doesn't help since having "s=spec" when there are multiple is kind of ambiguous. Perhaps "Open Container Runtime (ocr)" for the core spec we've been talking about. But if we view this all as one big spec (which might be nice to avoid each one having a different version number), then just "oci" would work.

wking · 2016-01-15T18:44:56Z

On Fri, Jan 15, 2016 at 10:35:34AM -0800, Doug Davis wrote:

Not to take us down too much of a tangent, but do we have one spec
or multiple in this project?

I would love to have this question answered, since I'm frequently
suggesting we handle orthogonal issues in separate OCI specs
(e.g. 1). But to stay on topic here, maybe we should move this
discussion to the list?

 Subject: Re: appc + oci harmonization progress
 Date: Thu, 13 Aug 2015 11:29:08 -0700
 Message-ID: <20150813182908.GS412@odin.tremily.us>

hqhq · 2016-01-18T04:07:45Z

We should leave the discussion about the needs of multiple OCI spec to the list.
LGTM

config: qualify the name of the version field

This reverts commit 0f25f18, opencontainers#253. Now that we're on to 1.0, we don't need to talk about 0.x. And the lack of 0.x backwards compatability is covered by SemVer 2.0 section 4 [1]: Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. so removing the echo from our spec doesn't actually change anything. The conflict is due to 4e63ee0 (config: qualify the name of the version field, 2016-01-13, opencontainers#309), and only impacted the context and line-wrapping around the sentence I'm removing. Conflicts: config.md [1]: http://semver.org/spec/v2.0.0.html Signed-off-by: W. Trevor King <wking@tremily.us>

wking reviewed Jan 13, 2016
View reviewed changes

vbatts force-pushed the version_name branch from 4b57e29 to 4df6c3b Compare January 14, 2016 20:54

mrunalp reviewed Jan 14, 2016
View reviewed changes

config: qualify the name of the version field

4e63ee0

opencontainers#110 Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>

vbatts force-pushed the version_name branch from 4df6c3b to 4e63ee0 Compare January 15, 2016 15:52

hqhq added a commit that referenced this pull request Jan 18, 2016

Merge pull request #309 from vbatts/version_name

ec7ca91

config: qualify the name of the version field

hqhq merged commit ec7ca91 into opencontainers:master Jan 18, 2016

hqhq mentioned this pull request Jan 18, 2016

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

Closed

vbatts deleted the version_name branch April 12, 2016 03:51

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

config: qualify the name of the version field #309

config: qualify the name of the version field #309

vbatts commented Jan 13, 2016

vbatts commented Jan 13, 2016

tianon commented Jan 13, 2016

vishh commented Jan 13, 2016

wking Jan 13, 2016

mrunalp Jan 14, 2016

vbatts Jan 14, 2016

wking Jan 14, 2016

jonboulle Jan 15, 2016

duglin Jan 15, 2016

mrunalp Jan 15, 2016

vbatts commented Jan 15, 2016

duglin commented Jan 15, 2016

tianon commented Jan 15, 2016

wking commented Jan 15, 2016

duglin commented Jan 15, 2016

wking commented Jan 15, 2016

hqhq commented Jan 18, 2016


		* `version` (string, required) must be in [SemVer v2.0.0](http://semver.org/spec/v2.0.0.html) format and specifies the version of the OCF specification with which the container bundle complies. The Open Container spec follows semantic versioning and retains forward and backward compatibility within major versions. For example, if an implementation is compliant with version 1.0.1 of the spec, it is compatible with the complete 1.x series. NOTE that there is no guarantee for forward or backward compatibility for version 0.x.
		* `spec_version` (string, required) must be in [SemVer v2.0.0](http://semver.org/spec/v2.0.0.html) format and specifies the version of the OpenContainer specification with which the bundle complies.

config: qualify the name of the version field #309

config: qualify the name of the version field #309

Conversation

vbatts commented Jan 13, 2016

vbatts commented Jan 13, 2016

tianon commented Jan 13, 2016

vishh commented Jan 13, 2016

wking Jan 13, 2016

Choose a reason for hiding this comment

mrunalp Jan 14, 2016

Choose a reason for hiding this comment

vbatts Jan 14, 2016

Choose a reason for hiding this comment

wking Jan 14, 2016

Choose a reason for hiding this comment

jonboulle Jan 15, 2016

Choose a reason for hiding this comment

duglin Jan 15, 2016

Choose a reason for hiding this comment

mrunalp Jan 15, 2016

Choose a reason for hiding this comment

vbatts commented Jan 15, 2016

duglin commented Jan 15, 2016

tianon commented Jan 15, 2016

wking commented Jan 15, 2016

duglin commented Jan 15, 2016

wking commented Jan 15, 2016

hqhq commented Jan 18, 2016