Remove EOL 18.09

[tao12345666333]

After modifying the maintenance cycle, 18.09 should have 7 months of maintenance time, and its actual release date is November 2018.

Docker maintainers try to have an overlap with the "next" release for a month or so; to give people time to upgrade to the next release, and to know that there's no major regressions in the next release that could be a blocker for people to upgrade.

18.09.9 will likely be the last patch release for 18.09.x, after which it will reach EOL.

[tianon]

I agree, thanks for the PR!

Just to confirm, @thaJeztah this is accurate, right? We're not likely doing another 18.09.x?

[tao12345666333]

The above is what I asked him before 😄
Thank you @thaJeztah

[tianon]

Hah, oops! 😅 ❤️

I also forgot that docker-library/official-images#6580 hadn't even been opened yet, let alone merged, so I've got that build test running now. 😅

[thaJeztah]

It's a bit fast to remove immediately, but guess it doesn't hurt; so w.r.t. maintenance cycle and the magical "7 months";

• releases are now every 6(ish) month(ish)
• one month overlap between the new and previous release (*)
• so, combined: 7 months

The "one month" overlap is a bit flexible, so perhaps better to describe the goal (using 18.09 and 19.03 as example here);

1. Do a new release (e.g. 19.03.0)
2. Give users a one month window to upgrade from the previous release (18.09.x) to the new one (19.03.0). The new release should® be all bright and shiny and unicorns 🦄 , and good to install at .0, but there might be some teething problems or regressions in (corner) cases that we didn't catch in testing, or some issues that weren't critical enough to delay the GA release, so some users might wait for the first .1 patch release
3. The "one month" is based on our frequency of doing patch releases, which is on a monthly base, so that one month effectively means; when the first (.1) patch release of the new release arrives.
4. Continue patching the previous release as usual (although we may be patching more selectively). The assumption here is that users won't upgrade to the 19.03.1 patch release on day one, and still want their existing 18.09.x install to be running smoothly while they prepare for upgrading (at least critical and security issues patched).
5. Patch some bugs in 19.03, watch for reports of regressions "in the wild", do a 19.03.1 release, and declare 18.09.x EOL

Now, the above is in the ideal situation. Reality doesn't always match that and, for example, when we released 19.03.0, we were finalizing a fix for an issue that was reported publicly, but turned out to be a security issue, so we had to do security releases (18.09.8 19.03.1)

Security releases should only contain the fix to patch the security issue at hand to minimise the risk of installing the security fix; including any other changes can increase the risk of regressions, which can lead to users delaying installing the fix. So 19.03.1 only had a fix for the security issue, but could still have other regressions since 18.09.x that may prevent users to upgrade to 19.03. Those (at least the most important ones) have been addressed in 19.03.2, so all users should now be able to upgrade to 19.03 and we can EOL 18.09.

I think we should be good here, but that said; it might be good to wait a short time (a week? slightly longer) to remove the previous release; we're all human (except for @GordonTheTurtle 🐢), so a hot fix could always be possible in the first few days after a release 😅

[tao12345666333]

Thank you for your detailed explanation @thaJeztah 👍
Maybe I am too anxious to upgrade to the new version as soon as possible. I will be more rigorous in this case, in the future.

In my actual situation, I usually perform continuous functional testing after the new version is released. Most nodes will be updated after verification.

However, there are a few nodes that are still on the 18.09.x version. As you know, maintaining multiple versions is not a good thing for consistency and maintenance costs. For these nodes, I can only upgrade it to 19.03 after 18.09.x EOL. 😟

After the last discussion with you, I have been waiting for the release of 18.09.9. 😄 But maybe I didn’t understand your last reply so thoroughly.

[tianon]

Totally fair (as usual), thanks @thaJeztah ❤️

We'll wait to push this PR up to https://github.com/docker-library/official-images until next week so it's easier to revert and stays in the "Supported" list on the Hub.

[thaJeztah]

Thanks!

[tianon]

... like maybe https://github.com/containerd/containerd/releases/tag/v1.2.9 for the gRPC CVE? 😅 😬

[tao12345666333]

Quick search, see some related fixes moby/moby#39798
and backport for 19.03 docker-archive/engine#340

[thaJeztah]

... like maybe https://github.com/containerd/containerd/releases/tag/v1.2.9 for the gRPC CVE? 😅

The CVE isn't nice, but for containerd it's not a critical issue, because (at least in a standard setup) it's only exposing its gRPC API through a local socket