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.

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).

Immediately before a release

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.