<story><title>Just say no to :latest</title><url>https://platformers.dev/log/2022-03-02-latest-literally-kills-puppies/</url></story><parent_chain><item><author>oxfordmale</author><text>This is always a balance. The moment you pin to a specific version you need to have a process in place to ensure you regularly upgrade to avoid introducing vulnerabilities in your production system. Throughout my career I have seen many cases where certain software still runs on ancient versions as the team originally maintaining it is no longer around (e.g. reorganisations or lay-offs). It is always hard to convince senior management to invest any resources to upgrade (If it works don&amp;#x27;t fix it)&lt;p&gt;If I have project that has good unit test coverage, I prefer to use :latest, as this results in a gradual update over time. If something breaks due to a version discrepancy, it is a lot easier to convince management to fix this, as the breakage would only be noticed as part of a feature request, and often would only require a small amount of work.</text></item></parent_chain><comment><author>peakaboo</author><text>I&amp;#x27;ve also seen the same. As soon as people start locking versions, that code is no longer updated and nobody will change it, because it&amp;#x27;s extra work to do so.&lt;p&gt;I personally think running latest is the best thing to do. And if something fails, you downgrade it temporarily until the latest work again. It&amp;#x27;s pretty much opposite to what is recommended, and it&amp;#x27;s just the best solution in my opinion.</text></comment>
<story><title>Just say no to :latest</title><url>https://platformers.dev/log/2022-03-02-latest-literally-kills-puppies/</url></story><parent_chain><item><author>oxfordmale</author><text>This is always a balance. The moment you pin to a specific version you need to have a process in place to ensure you regularly upgrade to avoid introducing vulnerabilities in your production system. Throughout my career I have seen many cases where certain software still runs on ancient versions as the team originally maintaining it is no longer around (e.g. reorganisations or lay-offs). It is always hard to convince senior management to invest any resources to upgrade (If it works don&amp;#x27;t fix it)&lt;p&gt;If I have project that has good unit test coverage, I prefer to use :latest, as this results in a gradual update over time. If something breaks due to a version discrepancy, it is a lot easier to convince management to fix this, as the breakage would only be noticed as part of a feature request, and often would only require a small amount of work.</text></item></parent_chain><comment><author>bheadmaster</author><text>In that case, it&amp;#x27;s better to just pin the major version of the container:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    FROM python:3
&lt;/code&gt;&lt;/pre&gt;
will work as long as Python3 doesn&amp;#x27;t make any backwards incompatible changes (note: Python3 occasionally deprecates then removes a feature that was part of the official API[0], so Python3 is not technically semver-correct).&lt;p&gt;If, however, one wants automatic updates WITH reproducible builds, then a CI&amp;#x2F;CD pipeline that automatically updates the FROM line in a Dockerfile on every upstream release is an only solution.&lt;p&gt;[0] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.python.org&amp;#x2F;3.10&amp;#x2F;whatsnew&amp;#x2F;3.10.html#removed&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.python.org&amp;#x2F;3.10&amp;#x2F;whatsnew&amp;#x2F;3.10.html#removed&lt;/a&gt;</text></comment>