Versioning Images and Docker Hub
Remember talking about versioning images in Topic D? We did that by adding latest and using some numbers against our images, such as 3.x.x or 3.x.x-rc.
In this topic, we'll go through using tags for versioning and look at how official images have been versioned in the past, thereby learning best practices.
The command in use here is the following:
docker build -t <image-name>:<tag> <relative location of the Dockerfile>
Say, for example, we know that Python has several versions: Python 3.6, 3.5, and so on. Node.js has several more. If you take a look at the official Node.js page on Docker Hub, you see the following at the top of the list:
9.1.0, 9.1, 9, latest (9.1/Dockerfile) (as of November 2017):
This versioning system is called semver: semantic versioning. This version number has the format MAJOR, MINOR, PATCH in an incremental manner:
MAJOR: For a change that is backward-incompatible
MINOR: For when you have a backward-compatible change
PATCH: For when you make bug fixes that are backward-compatible
You'll notice labels such as rc and other prerelease and build metadata attached to the image.
When building your images, especially for release to the public or your team, using semver is the best practice.
That said, I advocate that you do this always and have this as a personal mantra: semver is key. It will remove ambiguity and confusion when working with your images.
