feature request - semver labels

It can be difficult to know how to version images as there is no concept of a version number for images. There are tag's which are arbitrary, and that's it.

It would be great if docker / docker cli could support a semver versioning strategy for versioning images. Perhaps this could be an opt-in feature. Similar to how git flow is opt in for git repos that use git flow, then this might be an opt-in feature for images that want to use a semver versioning strategy rather than arbitrary tags.

To recap and give an example of some of the versioning difficulties: The latest tag for example can cause confusion. Pulling the latest tag of an image is not guaranteed to be any particular version of that image. It depends when it is pulled, and what was published at the time. If you see that an image with tag latest is running on two hosts, it does not mean they are running the same image. If you deploy the latest version of an image and then need to roll back to the previous version which was also latest at the time it was deployed, it's not obvious to know how to achieve that.

That's just one small issue and there are others. So for these kinds of reasons - its necessary to use a version number strategy when tagging images.

My/Image:1.0.0
My/Image:1.1.0

Given that semver dominates the versioning space and is used for versioning assets and builds of all kinds, it would make sense to me if there was some sort of supported workflow for this.

I don't propose any specifics at this stage, just floating the idea, but I will expand slightly with the kind of thing I was thinking.

Some thoughts:

1. Perhaps you could opt in to a semver workflow for an image a bit like so:

docker semver enable dazinator/dev

2. After the above, when pulling from docker pull dazinator/dev it would use semver strategy. It would pull the latest stable semver tagged image by default. If you want to allow a pre-release to be pulled: docker pull dazinator/dev -prerelease could could allow pre-release versions to be pulled. Ofcourse you could just pull a specific version as well.

3. When pushing images to a semver enabled registry, latest would be prohibited - as latest doesn't help much in the semver world - i.e does latest mean latest stable? or latest pre-release? In fact tags would now be validated against the semver spec to make sure they were valid semver version numbers.

4. When pulling a newer semver version of an image, (i.e it has a greater semver label) docker would tend to add a new seperate image to its image cache:

• 0.0.1 (10GB)
• 0.0.2 (10GB)
• 0.0.3-alpha0001 (10GB)
• 0.0.3-alpha0002 (10GB)
• 0.0.3-featureX-0001 (10GB)
• 0.0.3-featureY-0002 (10GB)
• 0.0.3 (10GB)

This is a problem that we have at the moment, and you soon find after a few deployments that disk space is being eaten up.

If the cli was aware that the image was using semver then it could automatically consolidate images in the cache to keep only the last X versions based on a configurable value. For example

docker semver enable dazinator/dev --keep-last 1

Would cause the cache to evolve like this:

docker pull dazinator/dev

image cache:

• 0.0.1 (10GB)

docker push dazinator/dev -t 0.0.2
docker pull dazinator/dev

image cache:

• 0.0.1 (10GB)
• 0.0.2 (10GB)

docker push dazinator/dev -t 0.0.3
docker pull dazinator/dev

image cache:

• 0.0.2 (10GB)
• 0.0.3 (10GB)

Notice that the image cache is consolidated to only keep the last stable release.

Obviously I couldn't help expanding a bit on a very high level idea :-)

No files, tests, or implementation entry points are named. Start by reviewing Docker CLI handling for image tags, pull and push behavior, and local image-cache cleanup; the work is not ready for implementation until the semver workflow, registry behavior, and cache-retention scope are specified.