About version numbers and such

[Peter Fendrich]

I don't know if this is a programming topic and not even if it's interesting at all but here it comes!
I've noticed how different engines uses completely different styles when it comes to version numbering. Often long number strings with almost no meaning at all. Terra is no exception. The latest one is Terra 3.3 beta11. This is a beta version that later on will be Terra 3.3. This is ridiculous for software that constantly changes
I've decided that my new engine Alaric wont have any beta versions at all or more accurate "all versions are beta versions"...
The version number will just be a date. My first release will probably be Alaric 0412, meaning December in 2004. If I for some stupid reason will relase another one during the same month I will add the day number. For instance Alaric 041224, meaning December 24 in 2004.

This at least makes some sense to me.
Comments
/Peter

[Alessandro Scotti]

Hi Peter,
usually I choose a goal (for version 1.0) and the version number reflects how far from that goal the program is.
For Kiwi, every 0.1 step means a significant step towards the goal. So version 0.1 could play chess (!), 0.2 had an opening book, 0.3 a completely new evaluation function, 0.4 probably a SEE and maybe king safety evaluation, and so on. I've also attached a letter to distinguish subsequent releases of the same version, which are mostly bug fixes.
In other programs I've published I've also experimented with different numberings, so for example my emulator Tickle is now in version 0.92 (first released was 0.90), my diff and merge program LCS is 1.11 beta because it adds several features to version 1.0 but is based on the same engine and not completely tested... ok you get the idea, sometimes one needs a bit of change even with the version id!

[José Carlos]

Dates make sense, buy also do version numbers. It is more or less an standard in software industry (AFAIK) to use three numbers: xx.yy.zzzz where xx is the release version, yy is increased when noticable changes are made and zzzz is increased everytime you build the project.
Myself, I don't do exactly that with my software. I use xx for big changes and yy for small changes, whereas zzzz versions are not fully tested. So I always release versions with zzzz == 0, but not yy == 0.
Also I don't get to version 1.00 until I believe I've a full developement. In case of Averno, I could have released version 1.00 because it's a full working chess program, but I have many search ideas that I want to try first.

[Uri Blass]

I use xx_y_zzz when xx is 00 as long as the program is not commercial and y is going to be increased only after zzz is going to get 999)

In the past I had only 2 digits and had movei00_7_99
I did not do big changes so at some points I changes my private versions to numbers like 00_7_992 but I decided at some point that I do not like it and it is better to start from 00_8 with 3 digits so I will have long time to improve to 00_9.

zzz is often increased when I do a new compile of the program but not always(there are cases when I do changes that are not relevant to playing strength and I am too lazy to update zzz)

changing zzz may mean only cosmetic changes with no change in playing strength and also may mean changing playing strength.

I also have the freedom to change zzz by more than 1 if I think that I did a significant change but usually I increase it by 1.

Uri

[Tim Foden]

For Green Light I've tried a number of different formats, but the current one is the one I've decided to use (of course! ).

For releases I use w.xx, where w is the major version number, and xx is the minor one. This is what I've done all along.

However, for my own testing, I have many versions to try, and I also want to keep track of them.

Generally, I test out ideas on the most recently released version, on a branch in CVS.

This is where I get the next number from: w.xx.y. The y is the branch number. Then I have versions on the branch, so I end up with w.xx.y.z.

So, my current release is 3.00, although I have a slightly bug fixed 3.01 that I've not released.

I've 'released' a couple of 'test' versions: 3.00.3.4 and 3.01.2.2.

I'm still using the 3.01.2 development branch at the moment.

Cheers, Tim.

[Richard Pijl]

In the Baron the version numbers follow the scheme x.y.z since version 1.0, where x is a major version number, y the minor version number and z the patch level.
Usually the y gets incremented on each release. Increasing x will mean that versions are not compatible in e.g. opening book usage or that another major change has been made (e.g. support of UCI etc.). Increasing the z is done when annoying bugs have been found in a released version. Sometimes the z is dropped from the version number, meaning that z=0.
Beta versions get the suffix b and a version number, and have already the main version number of the next release. I only make beta versions available to a small group of people, so confusion about that should be minimal.
Richard.

[Peter Fendrich]

Don't misunderstand me. Of course the ordinary software release numbering make sense. But mostly it makes sense to the developer himself.
As far as I can see we all do about the same. Namely some kind of main releases and in addition to that some numbers to show minor changes, bug fixes, beta versions or whatever. We need a safeproof way to keep track of all the versions we are using internally and to beta testers but it's probably a good idea to use a simpler scheme for released versions (as software houses often do). Our users are mainly tournament managers and other chess programmers and there are say 200 engines out there.
Keep it simple!
I will use my date standard even internally and can add as many levels I want to; day, hour, minute and even second but the release will be YYMM.
I think it has some merits to see how old the engine is just by looking at the version number. I don't even remember when my own engine, Terra3.3b11, was released.
/Peter

[Sune Fischer]

I decided it didn't make much sense for me to have the dots, there are no big or small changes, there are only changes.

Or at least regarding playing strength bugfixing one line can have as big an impact as rewriting the whole search.
Shredder is probably a good example of this with the 7.04 being a big jump from 7, while again a small jump from 7.04 to 8.

Somehow that seems a little silly, a smarter scheme is needed to reflect playing strength changes, IMO.

I also dislike the dot notation because it makes it less tranparent to me which versions have existed and which have not, ie. how many versions are there between 0.0.15.82 and 01. 13.34?

If I could redo it, I would have released with the plain and simple version 1, version 2 and so on. This is not possible so I will instead use version 200 version 300 etc.
Not that this numbering scheme necessarily has anything to do with the internal numbers used, I don't see why anyone should be bothered with my build version 15924.... numbers.

Actually I would really prefer to go by an automatic build count, doesn't matter if this counter reaches 10000 or more, it's not like we are going to run out of numbers.
This would be the cleanest i think, however it's a little tricky to set up in visual, a VB script must be implemented IIRC.

-S.

[Zach Wegner]

I have been on ZCT0.67 for a while, but that's just because I'm too lazy to make a new folder I usually just increment the number after every big change that seems to improve the engine a lot, I don't change the version much. If I am ever satisfied with it enough to release it, I will call it 1.0.