Eventstore: [RFC] What version should the Docker latest tag point to?

[hayley-jean]

Context

The :latest tag in DockerHub currently points to 20.10.2, which is the latest LTS release. However, the latest stable release is 21.2.0.

While using :latest as your image when deploying to production is against best docker practices, we should still decide on what version :latest will point to.

Proposed Decision

We can either do something similar to dotnet:

• :latest points to the latest stable release (21.2.0 in our case)
• :lts points to the latest LTS release (20.10.2)

Or we can do something similar to Ubuntu:

• :latest points to the latest LTS (20.10.2) because this is the version we recommend using in production
• :rolling points to the latest release regardless of LTS status (21.2.0).

Additional Context

If anyone feels strongly about this, or has other suggestions, please leave a comment on this issue

[oskardudycz]

Initially, I thought that I prefer the first option, as it's more straightforward and clear what :latest mean. However, I see that our scenario is closer to Ubuntu, as:

• New features are not back-ported to LTS.
• Bugs are generally not forward-ported to the newer version.
• We recommend using LTS and switching to the new versions when they need a specific new feature.

Having that, plus knowing that people might not follow the best practices for not using the specific tag on production, I'm voting for the second option.

[Gutek]

my two cents. as a product for me it would be nice to not to accidentally slip into not supported version. so I would root for :latest pointing to LTS.

as a user however of the docker I usually use :latest when I really want a latest release (not alpha, beta but latest version). In other cases I'm searching for a different tag. This is helpful with development and trying new things. I would have personally problem for going to docker hub trying to figure out what version should I use to have latest stable version.

Personally I also discourage usage of latest tag in teams - had few issues on production because of that. I would rather have specific version of ES docker image pushed to my team private repo. And only that image would be allowed to be used in production/staging.

so to summarize: I will understand if you will go with option :latest pointing to LTS, however I'm rooting for :latest pointing to latest.

[asbjornu]

Why not introduce a :stable tag pointing at the LTS and then have :latest pointing to the latest release? That would be the solution of least surprise to me, at least.

[nordfjord]

There's a third option that could probably be discussed: Don't have :latest at all

:20 would point to the latest 20.x release
:20.10 would point to the latest 20.10.x release
... etc

That would remove the footgun entirely

[alexeyzimarev]

I think it's good practice to have the latest tag.

[dnaprawa]

For me :latest is "latest version" of the image, and it's not recommended for production.
Anyone who wants stable (aka LTS) version should use a specific tag e.g. :lts

[ramonsmits]

Tag latest IMHO does not have any guarantees and should not be used in production. We (Particular) push public builds to a specific version (major.minor.patch ) and update latest to "greatest" major.minor.patch but as we apply SemVer we recommend customers to not use latest but pin to a specific major. This ensures that customers can always safely upgrade to the latest image might a major or major.minor get updated.

Our usage of latest is better suited for developers for a quick deployment of our platform tools as developers usually want to deploy the newest bits.

[ahjohannessen]

HAProxy uses something similar to that @nordfjord suggested.

[ahjohannessen]

The following is from HAProxy and seems reasonable:

• 2.4-dev19, 2.4-dev
• 2.4-dev19-alpine, 2.4-dev-alpine
• 2.3.10, 2.3, latest
• 2.3.10-alpine, 2.3-alpine, alpine
• 2.2.14, 2.2, lts

If I want 2.3.x I use 2.3 or if I want 2.2.x I use 2.2 - docker-library-bot updates tags as done here.