Docker Mailserver
Release policy - stables release updates #4221
-
|
When using the current stable release on tag "latest", DMS comes with an image that is missing several month of updates, including a a lot of security patches. I am a bit confused as to how DMS is intended to be used when the only alternative is the "edge" version that is explicitly not a stable release. The "latest" version has the following outstanding package updates as of today: |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
An image is built upon a tagged release and published. There are no updates to the image tag from that point on. You could add a Alternatively you can also A simple approach between those two is: services:
dms:
hostname: mail.example.com
# The `image` setting now represents the tag for the local build configured below:
image: local/dms:14.0
# Local build (no need to try pull `image` remotely):
pull_policy: build
# Custom build of DMS, extending it to include the `postfix-pgsql` package:
build:
dockerfile_inline: |
FROM docker.io/mailserver/docker-mailserver:14.0
RUN apt-get updateThat will build your own extended image of a DMS release and add a layer of updates on top of it. Force the build each time you would normally bump the image tag to update. This is the best way for you to ensure you get such updates/fixes that are external from DMS project itself. Generally we do not receive issues reporting fixes or updates resolving anything that's affecting anyone, unless it's a recently announced security vulnerability in which case maintainers react accordingly and push out a new release as was done with Postfix in the past as soon as a fix was available. If you would like to contribute scheduled updates for the official DMS image, it would need to ensure that it doesn't introduce regressions elsewhere in the CI. There is only a few volunteer maintainers for the project, the development flow unfortunately is fairly simple (PRs are merged into For this scenario it's probably ok to checkout the release tag and build the image again. It would need to ignore the build cache (and likewise probably not upload one afterwards), but if an update did introduce a regression that caused problems, you'd need to account for how to revert that to a previous image digest published for that tag. |
Beta Was this translation helpful? Give feedback.
An image is built upon a tagged release and published. There are no updates to the image tag from that point on.
You could add a
user-patches.shscript to your image that runsapt updateand this would be similar to pulling the same image tag as if it was republished with updated dependencies?Alternatively you can also
git clonethe repo for the release tag and perform your own local build. Force a rebuild each time you'd like to get the latest updates.A simple approach between those two is: