Add multi-level version tags to docker releases

[RoboMagus]

As I consider Vaultwarden to be a vital part of my selfhosted services I do not like to roll the dice and auto update my Docker containers and sticking to the latest label. However, manually updating the container version every time a new patch release is out is too manual.

This PR bridges the gap between the two. The rationale is well explained here, but the gist of it is that having the option to pin the docker tag to major, or major.minor allows users enable automatic updates up to the level they are comfortable with. I.e. automatically staying secure for security patches, but not automatically updating when a breaking change is introduced.

What this PR does:
When a new version is released, e.g. 1.34.5, and if this tag complies with SemVer formatting, the following tags are also added to the docker images:

• 1: Major version
• 1.34: Major.Minor version

(In case it does not match the SemVer formatting, nothing is added)

[BlackDex]

Well, we do not really follow semver. So it will not really help your case in any way.

Maybe with a very big change which will have huge impact we will switch to v2.

Also, i think something like this could also be fixed via the docker bake file, but not sure from the top of my head.

[RoboMagus]

Also, i think something like this could also be fixed via the docker bake file, but not sure from the top of my head.

I first tried implementing this inside the bakefile indeed. However, as part of the tag generation was already performed outside of it and I'm more comfortable with shell scripts it ended up a layer higher in the build process.

Well, we do not really follow semver. So it will not really help your case in any way.

Many projects don't actually follow that spec, but as long as some differentiation exists between whatever ends up between the dots additional tags would help bridge the gap between the too loose latest tag, and the overly specific complete version tags.

[BlackDex]

But if we release 1.34.0 tomorrow, you would still need to change it unless you use :1 which then doesn't help either, and for us it's the same as latest.

[BlackDex]

To say, I'm not fully against it. But i also do not want to provide false hope that this will solve anything. Since i think it won't, and maybe even keeps people on older versions actually.

[RoboMagus]

But if we release 1.34.0 tomorrow, you would still need to change it unless you use :1 which then doesn't help either, and for us it's the same as latest.

That's partially making my point for me. With this PR a user would be able to pin their tag to vaultwarden/server:1 and be assured of updates (i.e. tracking latest) until for some reason the bump to 2.0.0 is made. Which currently is not possible. Or alternatively indeed take it with one level more caution and stick to the minor version, e.g. vaultwarden/server:1.33 and have the option to automatically update to patch releases without the need to manually modify this every time. It is granularity in the update strategy that is currently lacking and may cause people to either auto update to a version that contains potentially breaking changes, or because they stick to a very specific patched version are not up to date on security releases / bug fixes.

Having the granularity instead of just the 1 options that exist currently provides users with more options to choose for the update strategy they feel most comfortable with.

To say, I'm not fully against it. But i also do not want to provide false hope that this will solve anything. Since i think it won't, and maybe even keeps people on older versions actually.

Using latest is often discouraged when deploying Docker containers. I especially would not like anything that handles critical data for me to be deployed in this manner. So currently that leaves as the only option manual updates every single patch release, or just sticking to older versions for long periods at a time. This may cause users to miss out on security patches, as well as breaking integrations with e.g. the android app (which has happened to me in the past).

[BlackDex]

And that makes my point clear as well, using your arguments, using :1 is not allowed either, since that basically is latest.

[BlackDex]

Also, we do not plan on any major release yet or in the near future as far as i can tell. But if we do, we would definitely try to make it clear, and then :1 would make sense.

But there better way's to fix this then this PR i think.
But i haven't looked at it that closely to be fair.

[RoboMagus]

using :1 is not allowed either, since that basically is latest

Why would :1 not be allowed? As far as docker tags are concerned that is a perfectly valid tag. And it's not basically latest as it offers a safeguard against auto upgrading to the next major version, which latest does not...

But there better way's to fix this then this PR i think.

I'm open to any suggestions to get this or anything similar merged. There's always multiple implementations to get the same thing done. But as far as practices go w.r.t. tagging docker images having multiple levels for users to specify what they're comfortable with, it is a helpful and common practice.

There's plenty of other articles and discussions on this topic as to why it is a good idea and almost all of the (larger) projects that I have come across already follow this practice. I'm just someone who would like to see it spread to other services that I rely on as much as a password manager.

[BlackDex]

I'm not saying it's not allowed. Im saying it basically is the same as latest in regards to Vaultwarden. And thus will not have the desired effect you are hoping on, and still need to change the version number a lot if you use :1.xx