We tag each release in the Sourceforge git at the time when we do an official release.
The parameter for the nant buildRelease will set the version number in the dll files, and in the version.txt of the client and the server.
This is important for building a patch, as soon as OpenPetra is used in production, for automatic updates of the clients.
Now for the releases that everyone can build from his own git branch:
You are responsible to use the numbers that make sense for you. I chose 0.0.14.5 since that version was not an official version, and the .5 was something I was quite sure I would not get to with the public version. Otherwise there could be confusion with versions downloaded from sourceforge and locally built customized versions.
Usually, the last number is used for the build, so each time you make a release, you should at least increase the build number (the 5 in the example).
The third number is the patch number, the second number is the release number. This is quite the same as with the old Petra. (eg 2.2.14 etc).
You should make your own tags in your git to keep track of your versions that you have built.
You can take orientation in the builds that we are doing for the official release, but you are free to release whenever it is important or relevant to you.
The additions to the config files resulted eventually in the 0.1 release. I would not have wanted to do a release just after such a change, since it is always better to wait a little when we find bugs in the developer versions. We did not release 0.1 just because of the config files though, but because over the past patches the quality steadily increased and we felt comfortable to do the first Alpha release.
The build numbers I usually only increase when we realise that there was a small glitch in the patch. This happened for 0.1.0.1 because 0.1 did not work on 64bit Windows. I did not even create a tag for that in git, although it could make sense to do that.
