You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A prior decision has been taken to not accept the + symbol on tag names. The documentation states it here :
After the image name, the optional TAG is a custom, human-readable manifest identifier that's typically a specific version or variant of an image. The tag must be valid ASCII and can contain lowercase and uppercase letters, digits, underscores, periods, and hyphens. It can't start with a period or hyphen and must be no longer than 128 characters. If you don't specify a tag, the command uses latest by default.
This goes directly against the semver notation, since semver accepts the + symbol as an indicator of build metadata.
The reasoning for this is that builds should not differ.
The issue is this is highly opinionated and there's several cases where this does not work:
When CI rebuilds an image, it may break it, then it is very hard to come back to previous for users apart for searching for the image SHA, which is less readable and meaningful for them
Build metadata is used for patching, but also forking an app. In this case we lose highly valuable information on the version of the image
The request is simple (even though accepting it and implementing it might be very complex depending on the pipelines affected) : accept + in tag names to fix semver compliance and give back this possibility to users
Thanks for opening. Unfortunately, this is not something that can be implemented in the CLI (or daemon, which does the actual handling for this) currently without breaking compatibility. Implementing this would need the change to be accepted and implemented in registries, other runtimes (such as containerd, and others), and possibly defined in some of the (OCI) specifications.
Some prior discussions can be found in (among others) below, and may contain further details;
Description
A prior decision has been taken to not accept the
+
symbol on tag names. The documentation states it here :https://docs.docker.com/engine/reference/commandline/image_tag/
This goes directly against the semver notation, since semver accepts the
+
symbol as an indicator of build metadata.The reasoning for this is that builds should not differ.
The issue is this is highly opinionated and there's several cases where this does not work:
The request is simple (even though accepting it and implementing it might be very complex depending on the pipelines affected) : accept
+
in tag names to fix semver compliance and give back this possibility to usersThis issue is linked to docker/metadata-action#385 and docker/metadata-action#384
The text was updated successfully, but these errors were encountered: