Developing software means a continuously changing code base. Not every version of the software is supposed to be installed in production. Most of the versions are pushed to the repository on a branch half complete. Some versions are meant only for testing and a few are meant to be installed in production even if only some of those will finally get to production.
Almost all the time, the releases follow the semantic versioning that we discussed in an earlier section. The versions that are meant only to be tested usually have the -SNAPSHOT modifier at the end of the version number. For example, the 1.3.12-SNAPSHOT version is the version that was once debugged, and is going to become the 1.3.12 version. The snapshot versions are not definite versions. They are the code as it is by then. Because a snapshot release never gets installed in production, it is not needed to reproduce a snapshot version for maintenance. Thus, the snapshot versions are not increased continually. Sometimes, they may be changed, but that is a rare exception.
It may so happen that we work on a bug fix, 1.3.12-SNAPSHOT, and during the development, we change so much code that we decide that it has to be 1.4.0 when it is released, and we rename the snapshot as 1.4.0-SNAPSHOT. This is a rare case. Many times, the release creation creates a 1.4.0 version from 1.3.12-SNAPSHOT as the decision about the new release number is taken by the time the release is created.
When the release process is started, usually from the web interface of the CI server, the developer creating the release has to specify the release version. This is usually the same as the snapshot version without the -SNAPSHOT postfix. The build process not only creates the build in this case but also tags the source code repository version it was using and loads the packaged program (artifact) to the code repository. The tag can be used later to access the exact version of the source code that was used to create the release. If there is a bug in a specific version, then this version has to be checked out on a developer machine to reproduce the bug and find the root cause.
If the build of a release fails, it can be rolled back, or you better just skip that release number and note it as a failed release build. An existing release can never have two versions. The source code is the only one that is for that release and the generated code has to be exactly the one in any storage. Subsequent compilation of the same source may result in slightly different code, for example, if a different version of Java is used to create the latter one. Even in such a case, the one that was created by the build server in the first place is the version that belongs to the release. When a bug is reproduced and the code is recompiled from the exact same source, it is already a snapshot version. Multiple releases may be possible from the same source version, for example, compiled with Java versions from 1.5 to 1.8 and version 9 but a single release always belongs to the exact same source code.
If a release that was supposed to be a release version fails during QA checks, then a new release has to be created and the failed release has to be noted as such. The version that marketing uses to name the different versions should not have a relation to the technical version numbers we work with. Many times, it is, and it causes much headache. If you realize that the two are totally different things and one does not have to do anything with the other, life gets simpler. Look at the different versioning of the Windows operating system or Java. As marketing, Java used 1.0 then 1.1, but Java 1.2 was advertised as Java 2 and still the code contained 1.2 (which now seven major releases later also becomes 9 instead of 1.9)
The last part of release management is that deployments should register the version numbers. The company has to know which release is installed on which server, and of which client.