New nant task: nant patchDatabase and Version numbers

pokorra

Previously, when building and developing OpenPetra, we always used version 0.0.9. This is not helpful, when reporting bugs etc.

Therefore, we keep now in step with the official release numbers.

This means, we have to update the development database, which the new task nant patchDatabase will do. This also allows us to extend the database between versions.

The version number is maintained in db/patches/version.txt

A question: How should we assign the version number?
For example: we currently have version 0.2.4 released. The developer version is already 0.2.5? when we report a bug as developers, do we mark it as version 0.2.4 or 0.2.5? When we fix a bug, should we set it to be fixed in 0.2.5?

christiankatict

This is a very good move.

The only question I have is on the numbering sceme for builds. In open source projects it is common to have even sub-version numbers (e.g. 2.4.xxx) for stable builds and non-even ones (e.g. 2.5.xxx) for builds consider unstable or development builds.

Is this what you mean? In that case I would be for introducing sub-sub-version numbers for unstable builds (e.g. 2.x.1) which we could increase manually (e.g. as defined development steps are finished), and for introducing sub-sub-sub-version numbers (e.g. 2.x.x.54) which could be increased automatically by our continuous integration system.

pokorra

I have not thought about that, having odd and even numbers.

But now it makes good sense.

So we released 0.2.4, and now we should call our development version 0.2.5. Once that is at a stage we want to publish it, we call it 0.2.6.

That way, we can fix bugs in 0.2.5 and set the version that they are fixed in to 0.2.6.

If we find a bug in 0.2.5, we probably should test if that bug was already in 0.2.4, and mark it accordingly.

christiankatict

So we released 0.2.4, and now we should call our development version 0.2.5. Once that is at a stage we want to publish it, we call it 0.2.6.

I agree.

That way, we can fix bugs in 0.2.5 and set the version that they are fixed in to 0.2.6. If we find a bug in 0.2.5, we probably should test if that bug was already in 0.2.4, and mark it accordingly.

Agreed.

What do you think about my proposal regarding sub-sub-sub version numbers? Having them automatically increased by an Integration Server task would be helpful if we want to do testing against a PetraClient/PetraServer version that is built using the Integration Server, which would make more sense than testing against a PetraClient/PetraServer that is built from a certain codebase which we have locally.
If we want to do testing against an Integration Server build, then it would make sense to keep at least one automatic build per day in an archive for some time. This way, if one tests against e.g. version 0.2.5.57 (where '57' is the auto-increased number) and finds a bug there which one suspects wasn't there before, one could get the last archieved build (e.g. 0.2.5.49) before the one that is currently tested (e.g. 0.2.5.57) and see if the bug was indeed not there. If this is the case, then one knows that the bug has been introduced between e.g. version 0.2.5.49 and 0.2.5.57 and one should be able to find out which check-ins have happened in the version control system (I suppose Hudson notes the version of each build in a log file, and also the check-ins that happened between different builds, so we could look into that log to determine the check-ins that happened between the builds).

pokorra

A build number is a good idea.
For releases, I have already used build numbers. eg. 0.2.4-4

The build numbers that you are talking about would only be on the central build server (hudson: ci.openpetra.org).
Each developer would have his own build system, and we cannot synchronize the build numbers.

We don't have a nightly build system yet, where people could download the binaries of a specific build for testing.

Also: Mantis only supports a combobox for the version, so it will be impossible to enter a specific build number.

I think we should release often, and it should not be a problem to have the 3rd digit go up in a week, once the development gets more and more momentum. But this is something we should also discuss in December in Carlisle.

christiankatict

The build numbers that you are talking about would only be on the central build server (hudson: ci.openpetra.org).

Correct.

We don't have a nightly build system yet, where people could download the binaries of a specific build for testing.

Well, maybe a nightly build system isn't really needed - we could possibly have a cron task that runs at 23:59 and 'zips' and copies the 'youngest' directory which contains build output to some place where it can be accessed via ftp...?

Also: Mantis only supports a combobox for the version, so it will be impossible to enter a specific build number.

That's not nice. Bugzilla does a better job at that.

I think we should release often, and it should not be a problem to have the 3rd digit go up in a week, once the development gets more and more momentum. But this is something we should also discuss in December in Carlisle.

I agree.