-
Notifications
You must be signed in to change notification settings - Fork 553
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
Conversation
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
|
@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. |
yes I know that's the intent but that's not what it says. :-) |
@duglin seems pretty clear for me.
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. |
does a 1.0.1 feature work in 1.0.0 ? |
@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. |
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? |
On Wed, Nov 18, 2015 at 04:00:49AM -0800, Qiang Huang wrote:
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 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)
|
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
as this only pertains to pre-release versions, it LGTM |
LGTM |
Clarify backwards compatibility for major version 0
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>
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>
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