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

Clarify backwards compatibility for major version 0 #253

Merged
merged 1 commit into from
Jan 13, 2016

Conversation

hqhq
Copy link
Contributor

@hqhq hqhq commented Nov 18, 2015

I think we agreed on this, but there is no docs for this, and it is easy to cause confusing as opencontainers/runc#406 and opencontainers/runc#406 (comment)

Signed-off-by: Qiang Huang h.huangqiang@huawei.com

Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
@duglin
Copy link
Contributor

duglin commented Nov 18, 2015

For example, if an implementation is compliant with version 1.0.1 of the spec, it is compatible with the complete 1.x series.
is this really true? If a new feature was added in 1.2 I wouldn't expect a 1.1 impl to support it.

@marcosnils
Copy link

@duglin what this really means is that if you have something that implements 1.0.1 it will still work with any 1.x series. Of course it won't support the new features, but you'll get guarantee that it won't break the current compatibility if you upgrade versions.

@duglin
Copy link
Contributor

duglin commented Nov 18, 2015

yes I know that's the intent but that's not what it says. :-)
Would be more accurate to say something like "features in 1.N will continue to wotk in 1.N+1"

@marcosnils
Copy link

@duglin seems pretty clear for me.

For example, if an implementation is compliant with version 1.0.1 of the spec, it is compatible with the complete 1.x series.
is this really true? If a new feature was added in 1.2 I wouldn't expect a 1.1 impl to support it.

What I understand from this sentence is that if I have an impl that runs un 1.0.1 it will still run with any 1.x series. Which I believe is the idea to communicate.

@duglin
Copy link
Contributor

duglin commented Nov 18, 2015

does a 1.0.1 feature work in 1.0.0 ?

@marcosnils
Copy link

@duglin if my runtime implements the 1.0.0 specs, even though I upgrade it to 1.0.1 it will still work (without the new features of course). I won't have the new features unless I update my runtime to support them.

@mikebrow
Copy link
Member

I figured the person writing the container was to put in his container the minimum version supported. Is the meaning of the version number more like a schema number?

@wking
Copy link
Contributor

wking commented Nov 18, 2015

On Wed, Nov 18, 2015 at 04:00:49AM -0800, Qiang Huang wrote:

I think we agreed on this, but there is no docs for this…

There are docs. We link to SemVer v2.0.0 1, which has a point 4:

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 I don't think we need to add a note reiterating that.

I do think we should drop the 1.0.1 sentence though, since (a)
compatibility is well covered by the SemVer spec, and getting all the
nuances right in a comment here is difficult and WET and (b) we
probably won't be cutting patch releases for the spec (more on this in
2).

 Subject: Versioning specs in the face of ambiguity
 Message-ID: <20150902035544.GJ32473@odin.tremily.us>

wking added a commit to wking/nmbug-oci that referenced this pull request Dec 29, 2015
Tag the thread about how we intend to version the spec.  See
additional version discussion in [1,2,3,4,5].

[1]: Subject: Re: Initial Draft Release
     Date: Fri, 11 Sep 2015 13:58:08 -0700
     Message-ID: <20150911205808.GC5912@odin.tremily.us>
[2]: opencontainers/runtime-spec#183
     New v0.1.1 tag doesn't match v0.1.0 in version.go
[3]: opencontainers/runtime-spec#253
     Clarify backwards compatibility for major version 0
[4]: opencontainers/runtime-spec#194
     Correct version from 0.1.0 to 0.1.1
[5]: opencontainers/runtime-spec#278
     Project: document release process
@vbatts
Copy link
Member

vbatts commented Jan 13, 2016

as this only pertains to pre-release versions, it LGTM

@crosbymichael
Copy link
Member

LGTM

vbatts added a commit that referenced this pull request Jan 13, 2016
Clarify backwards compatibility for major version 0
@vbatts vbatts merged commit 353631a into opencontainers:master Jan 13, 2016
@hqhq hqhq deleted the hq_version_compat branch January 14, 2016 02:13
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Jun 4, 2016
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>
Mashimiao pushed a commit to Mashimiao/specs that referenced this pull request Aug 19, 2016
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>
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

Successfully merging this pull request may close these issues.

None yet

7 participants