Providing immutable versions for minor releases

[josevalim]

Hi @getong 👋

Today we have an issue that whenever there is a new minor release, such as 23.0, we can't strictly depend on it. For example, when 23.0.1 is shipped, new deployments pointing to 23.0 will now change to 23.0.1.

While X.Y is meant to be fully compatible X.Y.Z, it may be possible that X.Y.Z introduces a regression, which breaks builds and production apps. Some may also be generally uncomfortable with the idea of depending on a mutable tag.

I also understand this is mostly an issue with Erlang versioning. The initial release is 23.0, which is also the Docker tag for 23.0.X, which leads to this ambiguity. However I believe it would still be desirable to address this problem. One simple solution would be to also publish 23.0 as 23.0.0, 23.1 as 23.1.1, and so on. What do you think?

Thanks for the time and for maintaining these images!

[getong]

23.0 as 23.0.0, 23.1 as 23.1.0 .
I will try to resolve it.

[tsloughter]

@josevalim to be clear, is making the OTP version static the only thing that has to be kept static? Or do the hash's of each tag need to be immutable?

My concern with keeping them completely immutable is mainly rebar3 then not being able to be upgraded.

I think, don't hold me to this, we shouldn't have to worry too much about OS changes, even security ones, because these images should not be used for running production nodes but only for building releases or other development.

But even tho the images are only used for building, it may be best security practice to be doing upgrades to the OS libraries for security updates only any way.

[josevalim]

I would say the important is to keep the Erlang version static but I don't have a strong opinion on the other bits.

[ericmj]

I would argue that no tags should be mutable unless it is explicitly documented that they are mutable and there is an alternative that is immutable.

There has been breakage in these images in the past because bugs were introduced in OTP patch versions and the tags were overwritten with the new, buggy OTP version. We are trying to fix it regarding OTP versions in this issue, but rebar3 can just as well introduce bugs in new versions as well, so why should rebar3 be automatically updated if OTP should not?

Additionally, things should not be updated unless there is a clear strategy for how it is being updated. Today I have no idea which rebar3 version I will be getting or when it will be updated in the future because it is not documented. AFAIK I can't tell which rebar3 I will be getting without fetching the image and running rebar3 -v.

Should rebar3 be included in these images? Elixir images are based on the Erlang images and I don't think they use the rebar3 installed by these images.

[tsloughter]

Mix is included in the Elixir images. These images are used for more than being the base for Elixir images :)

I at one point added the rebar3 version as a LABEL to the Dockerfile and Docker rejected it, saying instead to inspect the image's ENV docker-library/official-images#6621 (comment)

I thought it made sense to use labels and for image registries to display them as metadata and allow search with them... but nope.

[ericmj]

Mix is included in Elixir images but Mix is part of the standard distribution, explicitly version locked with Elixir, and never overwritten when pushing new tags. This means I always know which version I will get and it won't be automatically updated behind the scenes.

When is rebar3 updated in existing Erlang images?

[tsloughter]

Yes, but it is also an important piece of tooling needed by users of the image and is an annoyance if it were to have to be added manually in every image.

It is updated when there is a new release of rebar3, except for older OTP versions.

And since mix doesn't used the rebar3 installed it won't effect the Elixir images.

[ericmj]

Yes, but it is also an important piece of tooling needed by users of the image and is an annoyance if it were to have to be added manually in every image.

That's fair.

It is updated when there is a new release of rebar3, except for older OTP versions.

I am afraid then that we will try to fix the issue with OTP versions but it will still exist for rebar3. It's a very bad experience when an image that worked yesterday suddenly stops working today because the tag was updated behind the scenes, specially when it can continue to work on one machine but not another due to caching.

The issue is further extended with rebar3 since I don't know which version I am getting and there is no clear way to downgrade to the previous working version.

[tsloughter]

Yea, it is an annoying limitation of Docker lack of composibility and metadata.

It is a fact of docker images that users have to be made aware of and know to either "lock" (use a specific reference -- not tag) and/or mirror.

What can be done is in addition to having images like erlang:22 is to have images with tags like the ones you created for hexpm, erlang:22.0.0-ubuntu-20.04-rebar3-3.13.1-N.

The N since even with all that in the tag there is still the chance it has to be updated, I'll have to look to see if ubuntu updates their images from under tags like 20.04 for security updates, I assume they do, which would be why N would be incremented.

Which reminds me that another important best/required practice is to build your images with no-cache so you get an updated set of apt packages and install any important security updates. So users should be aware that keeping a static image is not good practice.

But would this be an acceptable solution? I think docker would accept these additional tags for the official images.

[getong]

As erlang:23.1.0.0 can be found in the docker hub, close this issue.