docker-dnsmasq
docker-dnsmasq copied to clipboard
jpillora
Upgraded dnsmasq to 2.82-r0
The last image was built 2 years ago, can we please get a newer alpine and the current dnsmasq please?
sure, do you know if this version of dnsmasq is fully backward compatible?
On Thu, 20 Aug 2020 at 18:16, Ivan Kurnosov [email protected] wrote:
The last image was built 2 years ago, can we please get a newer alpine and the current dnsmasq please?
You can view, comment on, or merge this pull request online at:
https://github.com/jpillora/docker-dnsmasq/pull/24 Commit Summary
- Upgraded dnsmasq to 2.82-r0
File Changes
- M Dockerfile https://github.com/jpillora/docker-dnsmasq/pull/24/files#diff-3254677a7917c6c01f55212f86c57fbf (5)
Patch Links:
- https://github.com/jpillora/docker-dnsmasq/pull/24.patch
- https://github.com/jpillora/docker-dnsmasq/pull/24.diff
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jpillora/docker-dnsmasq/pull/24, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE2X45UZX64I2R233DZKVLSBTLU3ANCNFSM4QFY57DQ .
It would be hard to guarantee, but from the changelog it looks there were no breaking changes: http://www.thekelleys.org.uk/dnsmasq/CHANGELOG
Because this image has millions of downloads, and unfortunately, only 1 latest tag. It would definitely break some people’s deployments if it did...
On Fri, 21 Aug 2020 at 7:59 am Ivan Kurnosov [email protected] wrote:
It would be hard to guarantee, but from the changelog it looks there were no breaking changes: http://www.thekelleys.org.uk/dnsmasq/CHANGELOG
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/jpillora/docker-dnsmasq/pull/24#issuecomment-677928217, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE2X447GVD6KQZ7CDYW3ALSBWME3ANCNFSM4QFY57DQ .
When somebody makes a decision to use a non-immutable tag - they need to weight the potential risks.
and unfortunately, only 1 latest tag.
Users should know better than to rely on latest tag for reliability.
Looking for a dnsmasq image myself, and while this was one of the first results listed in the DockerHub search, I was not sure if the 2 years since the last update justified it as a good choice (dnsmasq releases are infrequent, but keeping the alpine image updated is nice to have).
I figured it was still worth checking the project activity on github, so nice to see this discussion! A similar image would be andyshinn/dnsmasq, last updated 4 days ago, which is slightly different(no Web UI) but quite popular too. Maybe consider updating this image every 6 months too with the latest alpine?
EDIT: Oh... just noticed you're using alpine:edge.. that's about as bad as latest in my opinion, adopting this image is a nope from me :(
So based on the comments above. The plan is to tag the current latest as v1.0.0/v1.0/v1. Bump alpine up, and lock to an explicit version, and bump dnsmasq (hopefully) to 2.82. Bump webproc to v0.4.0. Then release this new version as v1.1.0/v1.1.
My main priority is not breaking the build of existing users, though it appears the changes to dnsmasq are backwards compatible.
Bump alpine up, and lock to an explicit version
You can't bump alpine:edge up, it's rolling. The current release is 3.12, but that will restrict you to dnsmasq 2.81.
Since you want to go with dnsmasq 2.82, continue to use alpine:edge and switch to alpine:3.13 next year.
Yes the tag is rolling though this image has not been rebuilt in quite some time. So yes, I would be bumping “up” with pretty much any alpine version I chose.
Since you want to go with dnsmasq 2.82, continue to use alpine:edge and switch to alpine:3.13 next year.
The reason it’s using edge in the first place was to use 2.78. However, I’m no alpine expert - I just after a small image. So if there’s good reason not to use edge, I’m all ears. If not, I think edge until next year is the way to go 👍
On Fri, 21 Aug 2020 at 9:53 pm Brennan Kinney [email protected] wrote:
Bump alpine up, and lock to an explicit version
You can't bump alpine:edge up, it's rolling. The current release is 3.12, but that will restrict you to dnsmasq 2.81.
Since you want to go with dnsmasq 2.82, continue to use alpine:edge and switch to alpine:3.13 next year.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/jpillora/docker-dnsmasq/pull/24#issuecomment-678252177, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE2X44K52WD5DZIRY3BK53SBZN4JANCNFSM4QFY57DQ .
So if there’s good reason not to use edge, I’m all ears.
It is the same reason you would not use latest tag for a Docker image in production. Just like how you raised the concern about your current users not wanting breakage. They would not get breakage with a versioned tag, but if they use latest, the next time they pull your image the version could have changed and they get a different image than they might have expected.
The same applies with alpine:edge, except it's when someone builds from the Dockerfile. For example I used an image that relied on edge but it had not been updated for 1-2 years. I thought no problem, the Dockerfile is available, I will just build it and add my fix. It was not able to build successfully, because it could no longer produce the same Docker image that was built for DockerHub at the time it was released there, none of the packages were the same and breaking changes had happened.
It was more a complicated Dockerfile, so fixing that was more work. Yours is very simple, so the risk is low. It would only matter if someone tried to build it in a year or so and thought they would get the same dnsmasq version as the DockerHub tagged version provided, which they can no longer do if they wanted to troubleshoot something.
I don't think you'll experience that problem. Just document on DockerHub/README what your tagged version uses for dnsmasq and webproc, that's basically all there is that matters in this image.
If not, I think edge until next year is the way to go
Agreed.