Does this mean there will be no distinction between major and bugfix releases any more?
Furthermore, this sheme will only allow one release per month.
It's also not semantic, so it will make it much harder for admins to maintain a stable environment.

@albers the distinction still exists, as you can see in the code, the new version is actually 17.04.0 you should see 17.04 as major and .0 as minor. I updated the PR body to reflect it.

We will also release 17.03.0 from the *17.03.x` branch, based on the 1.13.x branch.

So 17.03.0 will actually be 1.13.2? This is confusing because the number imples that it's a major update.
I'd prefer releases based on 1.13.x branch to retain their old versioning scheme.

This is confusing because the number implies that it's a major update

I think your critique is correct when considering docker/docker in isolation. Docker is making packaging changes that go beyond the code in this repo, and we're using the change in versioning scheme to emphasize those changes.

Would it make sense to do another big change at the same time? In particular, the difference between docker's version # and the API version # is confusing to many people. It would be nice if those two were always the same and we just had one version # to deal with. The original idea that the version #'s of the API and docker would be bumped at different times never really panned out.

Why are we switching away from semantic versioning? Also, what happens in the year 2100?

Why are we switching away from semantic versioning?

Going forward, we're going to stick a time-based release schedule and reflecting that directly in the versioning is a good way to emphasize that. Changing to a new versioning scheme is also a good way to emphasize the packaging updates we're introducing to make it clear what's pre-change and what's post-change.

@friism That still doesn't answer why we would move away from the best practices of semantic versioning. You can still do time-based releases and adhere to it.

Was there an announcement on the mailing list or a written document detailing this decision? I see an email in my inbox with a few hours notice for a meeting that happened this morning.

LGTM

Considering we cannot take any 1.X client and any other 1.Y server and have them work together, we are not fulfilling the requirements of semver as it is.

As commentary, I would suggest using the whole year vs the truncated version, to make it clear that it is indeed the year. It is the date, so use the date.

Considering we cannot take any 1.X client and any other 1.Y server and have them work together, we are not fulfilling the requirements of semver as it is.

With the API version negotiation added in docker 1.13, a docker 1.13 client is able to connect to older 1.12, or 1.13 daemons. Older clients are always able to talk to a newer daemon.

Basically, this doesn't change; e.g., a 17.10 client would be able to automatically negotiate API versions with 1.12, 1.13, and 17.03 .. 17.10 daemons, and can work with any daemon newer than that (17.11, 17.12, 18.01 etc)

So 17.03.0 will actually be 1.13.2? This is confusing because the number imples that it's a major update.

How about releasing 1.13.2 as 17.03.2? This feels a bit strange, but we retain the information that it is a patch release.

I also like the idea of using the full year in the version as proposed by @MHBauer.

@stevvooe we never supported semver, but our versioning scheme made people think we did, which there were many complaints about.

@MHBauer let's take ubuntu as an example, I think it's clear enough when you get 16.04 that 16 is the year, no ?

I'd like to know about #31075 (comment) ? It would be really nice to remove the current inconsistency we have at the same time as we do this.

@duglin Well, we just had to bump the API version on 1.13.1. So that would have thrown it off anyway.

@cpuguy83 I'm not following. If 1.13.1's version number was 17.03.01 and the api's version number was the same, what's the issue?

@duglin I think it's a change too big to be done at the same time, i'm afraid it will break many people.

And I'm not even sure we should have the versions be the same.

1.12.0, 1.12.1, 1.12.2, 1.12.3, 1.12.4, 1.12.5, 1.12.6 are all using API 1.24
1.13.0 is using API 1.25
1.13.1, 17.03.0 are using API 1.26

for all the 1.12.x I think it's good that we have the same API version

@vieux why is it a good thing that 1.12.x's all have the same versions? People clearly can't count on that because as you've shown 1.13.x's vary. So its random. And it does people a disservice for them to believe otherwise. How is that better than to say "each version of Docker has its own version of the API". And, people can then be explicitly clear about which version of the entire end-to-end docker they're using. We're supposed to be backwards compatible so bumping the numbers more often shouldn't hurt anything - especially when we encourage people to not use "latest" as the version.

It'd be nice to explain the benefits of this change in the documentation or somewhere. I'm sure the users would be happy to learn more about this.

Do you think we should have two sets of repositories? I expect some would like to upgrade only once in a while (to upgrade to bug fix releases and new longer term releases) and skip the intermediary releases.

LGTM

btw, I'm ok with resolving my questions around the API versioning scheme in a subsequent PR and letting this one be considered in isolation.

@shawnbutts with the upcoming releases, we're improving the maintainability of free Docker releases by adding a 1 month maintenance window overlap for quarterly releases. Since quarterly releases are supported for 4 months, there's a one-month window for upgrading where both the new and the old quarterly release is receiving security fixes. This is an improvement on the previous model where patches are not released for old versions at all.

For users interested in longer support windows, Docker maintains the Docker CS engine. We're working on making that clearer too.

Let me throw my hat into the ring and say this is a bad idea, like a really bad one. The problem with switching to this scheme is it's extremely hard to switch to a different one. My ADD prevents me from reading this whole thread but from what I've seen is the reason for this is "blah blah time-release, blah blah it's better, blah blah something about LTS."

The point being I don't really care a heck of a lot. I ship software too for my day job. I too have had way too many discussions about versions, release cycles, patching, etc. Basically all ideas are terrible, and the one you pick probably won't work well. It's an iterative thing to find what best matches your users. It sounds like you guys are pitching some process change that somehow helps you internally and somehow feel like switching the versioning helps. Well, it's doesn't, it's confusing....

The version is arbitrary nonsense, it's basically ${RANDOM CRAP}.${PATCH NUMBER}. So if RANDOM_CRAP=1.13 or =17.04, doesn't really matter. What I suggest you do is test out whatever new process you want, with the current version scheme. Only then if the process works you switch the versioning. All too often engineering gets great ideas like "We will just ship every month, the version number is useless, so we'll just say it's the month we released." So then april comes around and your about to ship 17.04 and feature X isn't ready.

Sales Guy:     "I promised feature X would be in 17.04 to customer Big Important Inc." 
Rock Star Eng: "Well we release monthly and it's not ready so its not going in."
Sales Guy:     "Delay the release, I need the feature, it's big $$"
Rock Star Eng: "No, I can't delay, it's a monthly release. Then 17.04 would be 17.05"
Sales Guy:     "Fine release today, but then give me a release next week with feature X"
Rock Star Eng: "No, a release in a week would be 17.04.1 and can't have new features.  You have to wait until 17.05"
Sales Guy:     "Fine release, 17.05 in a week from now"
Rock Star Eng: "No, 17.05 has to be release in May."
Sales Guy:     "WTF!? So you are telling me I have to wait another month because your pretty version number will be wrong"

So.... switching to 17.04 isn't good unless you have REALLY, REALLY thought this through, then tried something, failed 4 times, and then decided on this. Ubuntu's versioning is very clear, is 6 month release cycles, and a train of planning. This change seems cosmetic...

With the amount of justification provided here, it's hard to understand why this is a good idea. It seems to me like it will cause some amount of chaos and misunderstanding on the part of existing users, and probably require some changes to tooling and config management (at a minimum) by production users. Not necessarily a huge deal, but it would be great if you folks could spend some time better explaining to us why this is going to help us and is worth the pain. @alexellis suggested a blog post. Yes, please.

A longer commentary period would also have been appreciated. I suspect the end solution would have benefited from the additional input that would have provided. I guess some of us were still hoping you'd eventually embrace semantic versioning. Once you go down this road, that's off the table forever without a later breaking change.

@friism so the maximum amount of time i can safely have non-breaking changes is 4 month?

@shawnbutts Docker never intentionally has a breaking change except through the documented deprecation policy (which indeed needs updating for the new versioning/support scheme, on the todo list).

If you do run across a breaking change that was not communicated through the normal deprecation policy, please do file an issue so it can be addressed.

I'm not worried about communication. I'm worried about a "swarm" to "swarm mode" type change that will force a major production change. With only a 4 month "guarantee", there is a potential for up to 4 unplanned (outside companies control) changes to the infrastructure of production environments. Given the already tight schedules some of us work with, staying with docker may become a difficult sell to management.

If this decision was made, in anyway, to push people desiring a reasonable LTS version into a non-“Community Edition” version, it may impact our own internal push for docker.

@shawnbutts "swarm mode" is an enhancement to engine, "swarm" still works just fine with even the latest version of engine. It does not force any major production change unless it is something you want to take advantage of.

LGTM

I along with many other people was hoping one day for semantic versioning to be adopted and being able to rely on a versioning scheme that actually means something. Internal release processes come and go inside companies but versioning should be free of being affected by those. Even though the existing versioning system is less than ideal at least the community has made some sense out of it and knows what to expect. This changes those expectations and we will have to adapt.

There's nothing stopping anyone from checking out the code, building it on your own CI & installing it (And versioning it as you see fit)

Can you please elaborate on the internal discussion to change it to the time based versioning format? It would be good for the community to understand the context of the decision. Currently it seems that if you're going to adopt an versioning method, a proper adoption of a widely adopted and understood system, semver, seems like the best fit.

There is nothing to prevent you from doing monthly releases AND using semver. Some of our projects release weekly. Just do a minor release monthly, and patch it as needed. But treating the year as an X release, and forcing a HUGE BREAKING X CHANGE on everyone is going to cause problems.

1 -- what happens when you really DO need to make a breaking X change? Are you planning adding extra "little" years between 2017 and 2018?

2 -- How can anyone tell how major and significant the differences are, or the likelihood of breakage when they pick up the latest patch

3 -- What happens when you need to make a significant minor release in mid-month for a security fix?

4 -- what if the change between 17.12.002 and 18.01.001 is a tiny safe change? We take an X bump for no reason?

5 -- If other packages follow your pattern, then what happens on Jan 1, 2018? Is every other package using this ill-conceived scheme going to simultaneously release a new version at midnight?

If version numbers have no meaning, then I suppose they have no meaning. But I've seen not ONE reason listed as to why semver can't work for docker.

what happens when you really DO need to make a breaking X change?

We take API compatibility very seriously, and there's a separate API version that's not changing with the upcoming release.

Features are not usually removed, and if they are, they're deprecated well in advance. Details here: https://docs.docker.com/engine/#feature-deprecation-policy

How can anyone tell [..] the likelihood of breakage when they pick up the latest patch

As mentioned above, we take backwards compatibility seriously. If Docker breaks for you when moving from one version to the next, please open an issue so that the problem can be fixed.

What happens when you need to make a significant minor release in mid-month for a security fix?

A patch release would be issued, eg. 17.03.1

what if the change between 17.12.002 and 18.01.001 is a tiny safe change? We take an X bump for no reason

Under this scheme, "17" or "18" doesn't signify the magnitude of the change, it merely marks time.

Can you please elaborate on the internal discussion to change it to the time based versioning format?

To improve the predictability and cadence of Docker releases, we're adopting a monthly and quarterly release pattern. We hope this will benefit the project: Instead of waiting an indeterminate period of time after a PR is merged for a feature to be released, contributors will see improvements in the hands of users within a month.

A time-based version is a good way to underscore the change, and to signify the time-based release cadence.

Also: #31075 (comment)

Can someone clarify how a switching to a time based release schedule requires a time based versioning scheme?

Thank you.

@shawnbutts you're correct that switching the versioning scheme is not a requirement, but since it's a good way to underscore the change, and to signify the time-based release cadence, we decided to introduce it.

@friism, in my experience, opaque version schemes tend to create operational headaches. Judging by some of the comments here, I'm not alone.

There's a lot of time investing in tooling, automation, etc around docker. I would like to have a good level of confidence that docker-compose, a custom shell script, or my automation management of choice isn't going to break with a "yum update".

Can you or someone else point to successful projects where date based version have made things better from an operational perspective?

Thank you.

My concern about the new version scheme is that each time I will encounter a Docker version, I'll have to perform a mental modulo 4-operation in order to determine whether this is a monthly or a "LTS"/stable release.

I have added a discussion issue for SemVer for the Docker API #31842