In case you wonder what a fancy build number like 6.4.14.8131 really means, here is the rosetta stone for it:
[major].[minor].[iteration].[SVN revision]
[major]
This number is controlled by marketing. Marketing wants us to do at least "one big major release" every year to tell the press about it. Since business success is absolutely necessary to pay our bills, marketing does have a point. Usually we produce quite a lot of new functionality within a year and we try to save one big functionality chunk as the "marketing blurb" for a big release.
...but since marketing is the boss for the time schedule, don't expect a turn of the big version number to mean "stable, fully completed, refactored and already deeply tested by our 10,000 users".
( Developers (like me) always tend to see the functionality to be incomplete for a big release. It never is, right?
...or are you aware of any piece of software with 50,000 lines of code that you would call 100% complete ? )
[minor]
A turn of the minor number means that a build contains a substantial piece of completely new functionality in comparison to a previous minor version.
[iteration]
From this number you can see, in which week a build was produced. For our development process we use weekly iterations. We create weekly milestones and track completion of tasks against these weekly milestones. The iteration number will help you to find out which fixes are included, by looking at our changelog:
http://tracker.db4o.com/browse/COR?report=com.atlassian.jira.plugin.system.project:changelog-panel
If you see an important fix in a later version than you are using, looking at the changelog may tell you that it could be a good idea to switch to a later build, to get the fix.
[SVN revision]
This number is generated by our SVN source control system. It relates directly to a checkin.
By having the SVN checkin number available, we are able to reproduce a state in the sources and even branch an old version, should a user prefer to stay with the version he has and want just one single bug fix ported back. Since this is quite a bit of work for us and since it bloats our SVN, we can't offer this service for free, but in principle we are capable of adding maintenance for any version back in time.
Does all this make sense to you too?
Everything we produce immediately goes online with our continous build after all regression tests pass. Don't let the "date added" fool you, this is just a small insufficiency in our forum system. The continous build gets produced underneath, every day, you can find out by looking at the version number.
Since we are continously producing new and more regression tests, in theory this should mean that our product gets more and more stable with every single build we do.
This is true most of the time but not always:
db4o was not started with ruthless testing so there may be functionality that accidentally has been working for years and now got broken with a simple refactoring.
We just had such a case and we even had a discussion about it in our continous developer chat:
"Is anyone really using #peekPersisted() ? Where is the test case? Let's drop the functionality?"
We are now doing ruthless testing, in fact very very ruthless testing:
"Hey Carl, you added a line of code to the core. WhereThe.... is the breaking test case that told you to do that?"
We are catching up. With the process we are using we will get to the point that the very latest continous build will be the very best db4o version ever produced.
...and we are really looking forward to this point, because it will mean that all of our users will love to work with the latest build and we will get even more feedback for it even faster and stay on top of what you really need.
This is for you, our users.