Heritrix uses a version numbering scheme modeled after the one used for Linux kernels. Versions are 3 numbers:
[major ] .[minor/mode ] .[patchlevel ]
The major version number, currently at one, increments upon significant architectural changes or the achievement of important milestones in capabilities. The minor/mode version number increments as progress is made within a major version, with the added constraint that all external releases have an even minor/mode version number, and all internal/development versions have an odd minor/mode version number.
The patchlevel number increments for small sets of changes, providing the most fine-grain time line of software evolution. Patchlevels increment regularly for internal/development (odd minor level) work, but only increment for external releases when an official update to the previous release version has been tested and packaged.
Version numbers are applied as tags of the form "heritrix-#_#_#". Branches occur at major transitions and are labeled with the form "heritrix_#_#'.
When a particular development-version is thought appropriate to become an external/"st able" release, it is considered a "Release Candidate" (No where is this written in versions). If testing confirms it is suitable for release, it is assigned the next even minor/mode value (and a zero patchlevel), version-labelled, and packaged for release. Immediately after release, and before additional coding occurs, the HEAD is assigned the next odd minor/mode value (and a zero patchlevel) in project/source files.
If patches are required to a released version, before the next release is ready, they are applied to a branch from the release version tag, tested, and released as the subsequent patchlevel.
Keep in mind that each version number is an integer, not merely a decimal digit. To use an extreme example: development version 2.99.99 would be followed by either the 2.99.100 development version patchlevel or the 2.100.0 release. (And after such a release, the next development version would be 2.101.0.)