Remove version check in runc

[crosbymichael]

Signed-off-by: Michael Crosby crosbymichael@gmail.com

[duglin]

please please please! :-)
switching between branches, when it means a version switch, is painful

[duglin]

I know I'm probably in the minority on this one but IMO we shouldn't even need a version field in the json at all. If the semantics, or syntax, of a field changes (ignoring bug fixes) then we should define a new field and deprecate the old one. If you do that there's no need for a version field at all. Changing existing fields on people just causes more pain than its worth.
</rant>

[crosbymichael]

@duglin the version field is more for just v1 spec, v2 spec, large changes like that. we should be stable after we get the 1.0 out and stick to it

[LK4D4]

LGTM

[duglin]

@crosbymichael my assertion still holds. Large changes should use new field name to avoid confusion. It also allows you to add new fields w/o bumping up (meaningless) version numbers.

[wking]

On Thu, Jan 28, 2016 at 11:03:54AM -0800, Doug Davis wrote:

If the semantics, or syntax, of a field changes (ignoring bug fixes)
then we should define a new field and deprecate the old one.

How fast does that deprecation kick in? If we'd been doing that with
the current spec, it would be a huge mass of tried-and-abandoned
fields, runtimes would still have to check for a runtime.json which
may or may not be there, etc.

If we wait until 1.0 when the spec will hopefully settle down, then a
SemVer version check for any v1.x config will work with a current
v1.{latest} runtime. And we can still take your new-name approach,
never deprecate anything, and never have to go to 2.0. 2.0 is just a
flag day for clearing out the deprecated cruft if/when we decide that
needs to happen.

[crosbymichael]

This is not the place to discuss versioning policies for the spec

[jessfraz]

pleaseeeeeee i need dis

[mikebrow]

Plus one on either removing it now or changing it to a warning and removing it in May.

[cyphar]

@duglin

I know I'm probably in the minority on this one but IMO we shouldn't even need a version field in the json at all. If the semantics, or syntax, of a field changes (ignoring bug fixes) then we should define a new field and deprecate the old one. If you do that there's no need for a version field at all.

TBH, I don't really agree. Not having versioning means that we have to create new field names every time we decide old functionality was badly conceived. This happens a non-zero number of times, so why make it hard for ourselves? Not to mention that deprecating old functionality is slower than continental shift, while versioning ensures that we stay self-consistent in a single version of the spec.

[duglin]

@cyphar why? Mainly because of the pain caused by its presence - which is exactly why (I think) this PR was created. While there are examples where people include a version string, there are also lots of examples where they do not w/o any problems. For example, Makefiles and source code. I think the lack of a version string in source code is really interesting because progaming languages change all the time and yet they manage w/o it. W/o it, it forces them to be backwards compatible, have a well defined deprecation policy and have good growth/extension points. All good traits.

There are times when I think people use version strings as a "get out of jail free" card to pretty much make any changes they want (including breaking backwards compat) because they can just tell the user to use an old version string if they don't like the new stuff. That's not good for our users.

[crosbymichael]

This is not the place to discuss versioning of the spec and backwards compat. Please take it to the mailing list if you want to rehash an already discussed issue on how we are going to version.

[mrunalp]

LGTM