Immediately after a release is started (see Start the standard release process), the very next commit to the Batphone Git development branch is tagged with a “pre” tag for the next version number. See Batphone Git development branch for more information.
For example, the branch release-1.3 is created and release candidate testing commences. Meanwhile, other developers continue working toward the next release, which will be version 1.4. Their next commit to the Batphone Git development branch must be tagged 1.4-pre.
If no development work is done during the release (ie, no commits to the Batphone Git development branch) then the “pre” tag goes on the commit that merges the master branch into development (see Finish the release process).
At any time, the head of the Batphone Git development branch may be re-tagged with a new “pre” version tag, either to advance the “pre” count, eg, 1.4-pre2, 1.4-pre3, or to advance the version number itself, eg, 2.0-pre. Any tag is valid as long as it's version number is greater than the most recent public release and it is not a bugfix version number. See Batphone Git development branch for more details.
For example, shortly after starting release 1.5, a commit is made to the development branch, and is tagged with 1.6-pre. By convention, the next release would use 1.6 as its version number. However, if mesh protocol compatibility were deliberately broken during development of 1.6, the next release would have to be numbered 2.0. In this case, the development branch would get tagged with 2.0-pre shortly after that decision were made (leaving the various 1.6-pre tags in place).
As the first step in making a release, the version number is chosen. This will conventionally be the “pre” version number that was most recently used to tag the Batphone Git development branch, but it need not be. A last-minute decision may be made to use a different version number.
For example, suppose that shortly after releasing 1.5, development starts from the 1.6-pre tag but the first few commits are only to fix a critical bug. The development branch could be released straight away as version 1.5.1 (a bugfix release) instead of version 1.6.