Tagged releases + update

[clue]

[adambro]

Would you care to take a look at #5? What do you think, is there still any need for tagged releases in the future?

In theory Docker should provide a way to reproduce the same state on each build. In fact using adminer-latest.php in #6 is a kind of hack from this point of view. As an example Docker docs advise to specify which Ubuntu version you're basing from in order not to be affected when Docker switches to new LTS globally.

In practice though for such small project it might be an overkill. I'd get to tagging when / if things start to break due to dependencies change, i.e. Adminer requiring some PHP expensions or base package changes.

[clue]

In practice though for such small project it might be an overkill. I'd get to tagging when / if things start to break due to dependencies change, i.e. Adminer requiring some PHP expensions or base package changes.

Thanks for your valuable input!

I agree, I don't see any immediate need for this at the moment. Let's open up a new issue once a need arises (something breaks etc.)

[mikehaertl]

@clue I disagree. I don't see, why its a problem to always create a tag. It makes things clearer and users will always know, which version of adminer they are using. Right now it's very hard to find out:

1. No tags in clue/adminer
2. No specific adminer version in Dockerfile

So it could be anything, depending on when the image was built.

[clue]

Thanks for your input @mikehaertl, I think your making some valid points, so let's reopen this :+1:

[…] users will always know, which version of adminer they are using.

I think this point is very worth discussing. What do consumers of this package really care about? Given the nature of this image and Adminer in general, I personally see little point in using an outdated version, so I'm assuming most users will simply want the latest version. (this obviously does not account to all images)

I don't see, why its a problem to always create a tag

If consumers of this package need different versions, then I'm not against tagging releases. :+1: Until then, I'm seeing this to become an additional maintenance burden that will likely make consumers unhappy: A new release of Adminer is out, now let's wait for the image to update as well…

[mikehaertl]

A new release of Adminer is out, now let's wait for the image to update as well…

I'd say that's even more an argument for tags. Without a tagged image a user will never know, which version he's running. So if a new version of adminer is released, how would he ever know, if that version is used by this image?

In fact I think, the discussion is somewhat contrieved. In general it's just common practice to version tag docker images, so the adminer image should also be clear about the version.

[clue]

Thanks for your feedback so far, I'd like to hear some more opinions on this though.

This image is currently set up to automatically trigger a build regularly, see also https://hub.docker.com/r/clue/adminer/builds/ . Because each build always downloads the latest version, this also means that pulling the latest tag also always includes the lastest version of Adminer.

I consider this to be a good thing! It requires zero effort and still always includes the latest fixes and features.

Before #6 had been merged, this image required regular updates whenever a new version of Adminer had been released. Obviously, this requires effort and doesn't always happen immediately. As such, this involved a certain amount of delay before consumers of this image could even use new versions.

Currently, if you really need to target a specific version, you can still resort to pulling a specific SHA256, which targets an exact image build instead of a (mutable) tagged release only.

I understand that there may be valid use cases where it may make sense to download a specific version. However, so far, I have yet to see an actual demand, as literally nobody has asked for this within a full year.

Note that this image is usually directly exposed to the web (even if locally only) and not consumed as part of a larger infrastructure. This is unlike images such as "php", which absolutely requires tagged releases, because others build on top of this and often require specific versions.

[mathroc]

I agree with @clue I can't think of a reason to pin adminer to a specific version. Even if I had a very rare usecase where it would be needed, I would just copy this Dockerfile and adapt it to my needs. I don't think it's useful enough to put work/maintenance into that

[mikehaertl]

This image is currently set up to automatically trigger a build regularly, see also https://hub.docker.com/r/clue/adminer/builds/

As far as I know, that's not a feature of docker hub. Docker hub only provides a hook to rebuild the image whenever you push to the repository. So I wonder how this is implemented. If there's automation like this, then why not also go a step further and automate tag creation?

I really find it very odd to have no tags at all. No serious docker image would go without tags. Just check out the official images. If your image should cope in quality then tags are a must IMO.

[mikehaertl]

Contrieved scenario: You write a custom plugin that you use with this image (by sharing some local volume or the like). That plugin is only compatibly with 4.2.x of adminer. It works fine for you locally, because you never did a docker fetch and clue/adminer:latest is an old image.

Then some day your coworkers want to also use your plugin. But meanwhile adminer could be at version 5.0.x which is incompatible with your plugin. So your coworker are now stuck and have no way to get the older version.

Referencing images by hash is really cumbersum and only a dirty workaround. That's what tags where invented for.

[mathroc]

of course there is a few use cases where tags could be useful, there are also some really easy workaround, eg:

FROM clue/adminer
RUN wget https://www.adminer.org/static/download/4.2.4/adminer-4.2.4.php -O /var/www/index.php

so I can understand why one would not want to manage tags for very little benefits

[mikehaertl]

@mathroc If I need a workaround like this, then I don't need this image at all. I can build my own adminer from scratch.

Really: It seems that @clue is aiming for a professional looking image. If that's the case, tags are a must.

[mathroc]

@mikehaertl I do think tags are a plus. (and manage them on my images, eg: https://hub.docker.com/r/texthtml/phpcs/tags/) . just saying that IMHO, adminer can live without tags

[mikehaertl]

Here's a proposal to make everyone happy:

We point to the latest release in the master branch and create git branches for dedicated releases, e.g. 4.2.2 where we point to a specific adminer version. This can easily be automated with docker hub, so that clue/adminer:4.2.2 would be built from the corresponding 4.2.2 branch in this repo.

[clue]

I think we all agree that tags can be useful :+1:

Here's a proposal to make everyone happy: […]

I think this is a sane proposal, however this will involve quite some additional work for this repo, unfortunately, for (arguably) little gain.

If we can automate this so this is zero-effort, I'm not opposed :+1: