Generally, when referencing 3rd party packages (Docker base images, Maven dependencies, Ruby Gems etc.) it is worthwhile to be as specific as possible. You want to avoid randomly upgrading dependencies at a later time, just because there's a newer version out there, just because you only specified a prefix of the actual 3rd party release number.
I personally would do whatever it takes to make sure that I get the same upstream version on every build, forever, and that upgrading always is an activity I have to d, that is never done for me. For example, in Ruby, the bundler
keeps specific versions in the Gemfile.lock
. While the Gemfile
can specifiy vague versions (like "~> 3.1" giving you anything ">= 3.1 and < 4.0"), whenever a version is picked by the automatic resolving, the actual immutable version is fixed in the Gemfile.lock
and will never change on its own.
The reasoning is very simple - we use tools like Docker specifically to get out of the upgrade/version hell we had in the past; to make sure that we have the same versions on all environments, and to make changes visible (in the form of git
commits etc.). Introducing the same all over, by having "floating" upstream version numbers, would really be a shame.
There is really nothing elaborate like that Ruby Gemfile.lock
, for Docker base images, so in this case you have to look at the images you are pulling; they should document which tags are considered permanent. Then just specify those. And stay clear of latest
, obviously.
For your particular example, to pick at random, a version like 3.6.6-alpine3.7
seems to be pretty fully specified. I'd expect not much more than bugfixes from upstream. But if I were especially paranoid on that day, I might specificy a @digest
for the FROM (I'm not that paranoid normally...).
python:3
it means you don't care about the minor version, if you do cares, then specify it.docker run python:3 python3 --version
returnsPython 3.11.2
for me though.