<p>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.</p>

<p>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 <code>bundler</code> keeps specific versions in the <code>Gemfile.lock</code>. While the <code>Gemfile</code> can specifiy vague versions (like "~> 3.1" giving you anything ">= 3.1 and &lt; 4.0"), whenever a version is picked by the automatic resolving, the actual immutable version is fixed in the <code>Gemfile.lock</code> and will never change on its own.</p>

<p>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 <code>git</code> commits etc.). Introducing the same all over, by having "floating" upstream version numbers, would really be a shame.</p>

<p>There is really nothing elaborate like that Ruby <code>Gemfile.lock</code>, 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 <code>latest</code>, obviously.</p>

<p>For your particular example, to pick at random, a version like <code>3.6.6-alpine3.7</code> 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 <code>@digest</code> for the FROM (I'm not that paranoid normally...).</p>

CC BY-SA 4.0
2018-08-04T23:15:36.290Z
2018-08-04T23:21:10.987Z
2018-08-04T23:21:10.987Z
AnoE
<p>From the official Docker hub repository at <a href="https://hub.docker.com/_/python/" rel="nofollow noreferrer">https://hub.docker.com/_/python/</a>.</p>

<blockquote>
  <p>Shared Tags</p>
  
  <ul>
  <li>3.7.0, 3.7, 3, latest:
  
  <ul>
  <li>3.7.0-stretch (3.7/stretch/Dockerfile)</li>
  <li>3.7.0-windowsservercore-ltsc2016 (3.7/windows/windowsservercore-ltsc2016/Dockerfile)</li>
  <li>3.7.0-windowsservercore-1709 (3.7/windows/windowsservercore-1709/Dockerfile)</li>
  </ul></li>
  </ul>
</blockquote>

<p>Based on that, I assume version X will be a tag of latest X.Y.Z.</p>

CC BY-SA 4.0
2018-07-05T22:15:24.123Z
2018-07-05T22:15:24.123Z
Henrique Gontijo
<p>I have a Python application that I want to containerize with Docker. Should I use <code>FROM python:3</code> or <code>FROM python:3.7</code>?</p>

<p>Does the <code>python:3</code> tag automatically use the latest minor version of Python? Would there be a practical reason to pin to version 3.7 explicitly?</p>

<p>I could not find a clear answer to these questions in the <a href="https://hub.docker.com/_/python/" rel="nofollow noreferrer">official documentation</a>.</p>

CC BY-SA 4.0
2023-03-21T00:21:44.323Z
When run use `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` returns `Python 3.11.2` for me though.
deFreitas
<docker>
Dockerfile base image
Dylan Klomparens
# Dockerfile base image

(Asked by: username_0 on 2018-07-05)

I have a Python application that I want to containerize with Docker. Should I use `FROM python:3` or `FROM python:3.7`?

Does the `python:3` tag automatically use the latest minor version of Python? Would there be a practical reason to pin to version 3.7 explicitly?

I could not find a clear answer to these questions in the [official documentation](https://hub.docker.com/_/python/).

**Tags:** docker

> **Comments:**
> **username_1**: When run use `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` returns `Python 3.11.2` for me though.  

---

## 2 answers

### Answer by username_2 on 2018-08-04. Score: 2 | Accepted answer

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


---

### Answer by username_3 on 2018-07-05. Score: 1

From the official Docker hub repository at <https://hub.docker.com/_/python/>.

> Shared Tags
>
> * 3.7.0, 3.7, 3, latest:
>   + 3.7.0-stretch (3.7/stretch/Dockerfile)
>   + 3.7.0-windowsservercore-ltsc2016 (3.7/windows/windowsservercore-ltsc2016/Dockerfile)
>   + 3.7.0-windowsservercore-1709 (3.7/windows/windowsservercore-1709/Dockerfile)

Based on that, I assume version X will be a tag of latest X.Y.Z.


---

