I used to simply use the ‘latest’ version tag, but that occasionally caused problems with breaking changes in major updates.
I’m currently using podman-compose and I manually update the release tags periodically, but the number of containers keeps increasing, so I’m not very happy with this solution. I do have a simple script which queries the Docker Hub API for tags, which makes it slightly easier to find out whether there are updates.
I imagine a solution with a nice UI for seeing if updates are available and possibly applying them to the relevant compose files. Does anything like this exist or is there a better solution?
Are they documented separately from other changes?
They’re usually clearly documented in support forums by people saying “MY STUFF WON’T BOOT PLESE HALP”
It depends on the project. If the project doesn’t make an effort to highlight them I would consider using a different one.
But any decent OSS will make a good change log for their updates that you can read.
I’ve just been updating my containers every week or so and if something breaks I’ll try and fix it. It would definitely be preferable to “fix” in advance, but with enough containers getting updated, checking/reading every change becomes a fair amount of work. Most of the time nothing breaks.
Downvotes are cool but if this is a bad way of doing things just tell me.
What is driving you to need to update so often?
Nothing. Is this too frequent?
Well, there’s always the “if it ain’t broke don’t fix it” mantra. There’s a few reasons I tend to update. Because there’s a feature I want or need, to fix a big that affects me, or because a software frequently updates with breaking changes and keeping up with reading change logs is the best way to deal with that. The last option is usually because if I keep up with it I don’t have to read and fix multiple months of breaking changes.