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
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...).