As mentioned earlier, the build systems need to produce artifacts in a reliable way. This requires that Java artifacts are built and archived with a distinct version, which is identifiable later on. Software tests verify specific versions of enterprise applications. Later deployments need to refer the identical versions in later build steps as well. Being able to identify and refer to distinct artifact versions is necessary. This is true for all binaries.

One of the 12-factor principles is to explicitly declare dependencies, not only for dependencies being used but also in regard to their versions. As mentioned earlier, the same holds true for container builds. Specified Docker base images as well as installed software should be explicitly, uniquely identified by their versions.

It is quite common, however, to specify Java builds as snapshot versions, for example, 0.1-SNAPSHOT. A snapshot, as opposed to a release version, represents a software state which is currently being developed. Dependency resolution always attempts to include the latest snapshot when several snapshot versions are existent, comparable to the Docker latest tag. The workflow behind snapshots is to release the snapshot version to a uniquely numbered version, once the level of development is sufficient.

However, snapshot versioning contradicts the idea of Continuous Delivery. In CD pipelines every commit is a potential candidate for production deployment. Snapshot versions are naturally not meant to be deployed on production. This implies that the workflow would need to change the snapshot to a release version, once the software version has been sufficiently verified. However, once built, Java artifacts are not meant to be changed. The same artifact that has been verified should be used for deployment. Therefore, snapshot versions do not fit Continuous Delivery pipelines.

Following the widely adopted approach of semantic versioning, application developers need to take care of their versions in regard to backward-compatibility. A semantic versioning describes software versions such as 1.1.0, 1.0.0-beta, or 1.0.1+b102. In order to represent versions that are both eligible for Continuous Delivery and provide semantic versioning metadata, properly numbered versions with unique build metadata are a good solution. An example is 1.0.1+b102, for major version 1, minor version 0, patch version 1, and build number 102. The part after the plus sign represents the optional build metadata. Even if the semantic version was not changed in between a number of builds, the produced artifacts are still identifiable. The artifacts can be published to an artifact repository and retrieved via these version numbers later on.

This versioning approach targets enterprise application projects rather than products. Products which have multiple shipped and supported versions at a time, require to have more complex versioning workflows.

At the time of writing, there isn't a de facto standard for versioning containers yet. Some companies follow a semantic versioning approach whereas others exclusively use CI server build numbers or commit hashes. All of these approaches are valid, as long as container images aren't rebuilt or distributed using the same tag twice. A single build must result in a distinct container image version.