Generally speaking, the version numbers consist of three parts: “x.y.z”, with the parts x, y, and z.
Following a bit of an explanation what these numbers (might) mean:
- x
- Main version number, currently - and probably for long time - “0”
- y
- Release number
- even numbers refer to “stable” versions, odd numbers refer to development versions
- z
- Sub-release number
- For stable releases mainly bug fixes or minor new features.
- For development releases every new development version that is referred to as reasonably stable to be tested.
Please note: Not any commit to the development branch is identical with a developers release. It is rather that new or improved features get labelled with a new release number, as this is reflected in the toolbox version itself and helps to track possible problems. Nevertheless, even for the advanced user who uses those developers versions rather than the (hopefully) more stable official releases, it is normally recommended to use but just the developers releases. That might get reflected once in the git repository structure.
Version numbers are basically unlimited, one number in the scheme does not influence any higher number.
Basically, that means that after v.0.0.9 comes v.0.0.10, rather than v.0.1.0.
But if there is a change, say, after v.0.3.27, to an official 0.4.z release, that becomes 0.4.0, and subsequent developers releases are then 0.5.1, 0.5.2, etcetera.
Any new or improved feature that might get used by others than the author of the toolbox during the actual development should lead to a new developers release number (z in the above scheme).
Most probably, there will be no real support for older versions any more, unless there are good reasons for that.
Once there is an official release, it is planned to keep further developments as backwards-compatible as any possible.
This is one reason not to hurry too much with getting a first/the next “official release”.
On the other hand, as soon as the toolbox gets used regularly, regardless in what version, there might be a need for a first official release and therefore some care with backwards compatibility.
There is a good (German) article available on heise.de covering this topic.
The “original” scheme is known as “Semantic Versioning” (SemVer), details can be found on the respective SemVer homepage.