Hacker News Reader

Comment by friism | Hacker News Reader

We take backwards compatibility seriously. If you encounter problems updating from one version of Docker to the next (whether from 1.13.1 to 17.03 or from 17.03 to the upcoming 17.04), please open an issue on docker/docker so that can fix the incompatibility and improve our change process.

Quoting from the blog post:

    The Docker API version continues to be independent of the
    Docker platform version and the API version does not
    change from Docker 1.13.1 to Docker 17.03. Even with the
    faster release pace, Docker will continue to maintain 
    careful API backwards compatibility and deprecate APIs and 
    features only slowly and conservatively. And in Docker 
    1.13 introduced improved interoperability between clients 
    and servers using different API versions, including 
    dynamic feature negotiation.

- https://blog.docker.com/2017/03/docker-enterprise-edition/

View on HN

Docker takes backwards compatibility so seriously they wholesale block the client and server from communicating with each other if they differ by a single minor version.

Docker takes backwards compatibility so seriously they've released multiple versions of a docker registry all with completely new APIs.

Sorry if I don't buy it.

In terms of client server communications, that's no longer true: https://github.com/docker/docker/pull/27745

> Docker takes backwards compatibility so seriously they wholesale block the client and server from communicating with each other if they differ by a single minor version.

That has been fixed. Note that this limitation (although it turned out to be annoying, which is why we removed it), did not actually break reverse compatibility in the API. It just made the client excessively paranoid about reverse compatibility. In other words the client didn't trust the stability of the daemon enough, even though the daemon in pratice almost never broke compat.

> Docker takes backwards compatibility so seriously they've released multiple versions of a docker registry all with completely new APIs.

I'm not sure what you're referring to, but I will look into it. Is this still affecting you? Or is it a past problem you are still pissed off about?

With all due respect, this is exactly the attitude that will prevent enterprises from ever taking Docker seriously.

Why should enterprises trust you on backwards compatibility when longstanding issues with backwards compatibility were just fixed and then glossed over like this ("it never broke in practice because we forcibly made you update")? Docker has repeatedly made poor decisions with really poor optics both in the open source community and with their product, this is just one example, and asking enterprises to just trust you now while not even providing the support terms most of the enterprise world demands is doing the exact opposite of inspiring trust.

Do you honestly not remember sunsetting the python docker registry just a year and a half ago and then introducing a brand new golang registry product with an entirely different API? Because that's precisely what enterprises pay to avoid, they don't shell out absurd money for LTS versions to hit a constantly moving target. And please don't patronize me with "past problem", some of us lowly end users of your product had to clean up that mess just to get day to day operations working again. Forgive me if I'm gunshy.

My intention is not dismiss your complaint, but to gather more details so I can help.

Here is a list of known past breaking changes in the Docker API. https://docs.docker.com/engine/breaking_changes/

If you have encountered a breaking change that is not on the list, could you mention it either here or on https://github.com/docker/docker.github.io ?

Some of your claims about breaking backwards compatibility above are incorrect. I am trying my best to point that out without seeming dismissive of your overall point - which I think is that Docker can do more to improve stability and backwards-compat. I agree with that point.

pdeuchler expressed skepticism about Docker's current compatibility statements based on Docker's historical compatibility practices.

Suggesting that this could be "a past problem [he's] still pissed off about" comes across as tone-deaf when the underlying issue is Docker's credibility when it comes to backwards compatibility.

The quarterly ("stable channel") CE releases (17.03, 17.06 and so on) are supported for 4 months, and will not get new features during that period. EE quarterly releases have a 1 year support period, and also won't get new features.

During the support period, bug fixes will get back ported to those versions and released as "patch" releases (e.g. 17.03.1).

When installing, you can choose to install either the "stable" (quarterly) channel, or the "edge" (monthly) channel.

This seems to carefully avoid making any promises about the future. Where SemVer _does_ make promises.

Also, picking a date for versioning is weird as it doesn't contain any information other than when the Changelog was set in stone. Too bad this decision was made, and Docker choose not to value the stability of SemVer.

We most definitely WILL respect SemVer where it matters: the API versions.

Docker is a collection of many different components, exposing many different interfaces. Semver in Docker version doesn't make sense for the same reason it doesn't make sense in Ubuntu or Windows.

Cool, thanks for stressing this! I'm fine with not choosing Semver, but a date holds not guarantees on backwards compat, nor any other useful info. But I do get you'd like to version components the same to stress those are meant to be used together.

If you're going to say that, you really should build your packages appropriately. e.g, right now, you have:

$ repoquery -q --provides docker-engine-17.03.0.ce-1.el7.centos docker-engine = 17.03.0.ce-1.el7.centos docker-engine(x86-64) = 17.03.0.ce-1.el7.centos

...compare to, say, python (I've elided a few things for clarity):

$ rpm -q --provides python python = 2.7.5-48.el7 python(abi) = 2.7

If you do something like: Provides: docker(api) = 1.23

... this at least means that folks can depend on/install 'docker(api) > 1.23' or whatever if they actually want to get a specific semantic version.

That's good feedback, thanks.

Reply on news.ycombinator.com