Versioning

[Kempelen]

When I had to versioning a doc or a program, I only make a copy raising a counter in the name. I had never used a serius system before, and now I am thinking on useing something reasonable for the engine I am writting.

I have seen that in lot of software people use nn.nn or even three or four (nn.nn.nn , nn.nn.nn.nn). What is a good politics to versioning this?

I am very diligent and are trying to do things fine from start, althought the engine will finish in month or years.

thx
FS

[wgarvin]

It doesn't matter what scheme you use as long as you can tell which ones are newer or older. A major and minor version number is probably enough (e.g. version 1.20 or 14.5 or whatever). Many programmers start with a major version of zero, and a smallish minor number (like maybe 0.20), because they want 1.00 to be a kind of milestone in the life of their program---the first fully-feature-complete release of it, or something like that. Maybe the program is considered "beta" as long as the version number is less than 1.00, and its considered "production quality" after that point.

[Edit: also, you can always start with major dot minor, and then decide to add more numbers later if you want to. But you probably won't want to.]

How you use the numbers is totally up to you. You can make up your own versioning scheme to suit your own needs, or you can just use major and minor because everyone else is doing it. I've seen projects where an automated build system included as part of the executable the date and time of the build, the username doing the build, a unique build number, and sometimes even a manifest listing of the file revisions of every source file that was part of the build! But this sort of thing is totally overkill for most projects, and all they really need is a major and minor version number, and maybe a date (for nostalgia purposes, just for when you find a really old version of your program---so old that you can't even remember what month or year you released it in!)

[Carey]

You can also do it by date. 2008.03.11, for example.

Or if you plan to release on a semi-regular schedule, you could do 8.3 (meaning 2008, month 3)

If you are using any form of source control (SVN, SUbversion, whatever), you could base the release version on the version number there.

You could also just keep it simple.... Do incrimenting version numbers. 1, 2, 3, etc. Or tack that onto some other scheme, so you have something like 2008.03.11.b987 meaning build number 987 that was done on 2008, March 11th. That kind of versioning is often done for nightly builds in the open source world.


For most cases, I think a simple major.minor works fine. Especially when the minor number isn't limited to just a single digit.

If you need to revise a part you had already recently worked on, or a minor bug fix, then you can add a sub-minor number. Go from 2.4 to 2.4.1 for example.

That can be extended, of course. Reminds me of some of the version numbers of some old software back from the 8-bit micro days. Sometimes there would be version numbers like 8.32.7.104.94 Always made me wonder just how many bug-fixes did they need??!

[Ovyron]

I support the date idea!

For most cases, I think a simple major.minor works fine. Especially when the minor number isn't limited to just a single digit.

What I dislike is when they mark a minor update 10 with the number 10, because in math: 1.1 = 1.10, so the versions:

1.0 - 1.1 - 1.2 - 1.3 - 1.4 - 1.5 - 1.6 - 1.7 - 1.8 - 1.9 - 1.10

Looks confusing (as if after 1.9 you go back to 1.1, because 1.10 looks a lot like 1.1.0)

So, I suggest to just avoid that. (You could go to letters, like 1.A, or 1.9a or something like that.)

[wgarvin]

I support the date idea!

For most cases, I think a simple major.minor works fine. Especially when the minor number isn't limited to just a single digit.

What I dislike is when they mark a minor update 10 with the number 10, because in math: 1.1 = 1.10, so the versions:

1.0 - 1.1 - 1.2 - 1.3 - 1.4 - 1.5 - 1.6 - 1.7 - 1.8 - 1.9 - 1.10

Looks confusing (as if after 1.9 you go back to 1.1, because 1.10 looks a lot like 1.1.0)

So, I suggest to just avoid that. (You could go to letters, like 1.A, or 1.9a or something like that.)

What a lot of programmers do is choose to have their minor version number always be two digits (or maybe, always be three digits). So they have version numbers like: 0.20, 0.21, 0.22, 0.25, ... 0.91, 0.92, 0.95, 0.99, 1.00, 1.01, etc. The advantage here is that you can read it just like you would read a normal real-valued number, and the normal ordering for real-valued numbers also puts these version numbers in the correct order (i.e. 0.20 < 0.22 < 0.91 < 0.95 < 1.00).

Of course, what happens if you have 0.95 and you're getting kinda close to 1.00 but you don't think the program is mature enough yet to label it 1.00, because you want to save 1.00 for the first "non-beta" release? In fact, by 0.95 you might feel you are getting uncomfortably close and you might not want to go up to 0.98 or 0.99 because people will mistakenly feel that those versions are "almost, almost non-beta" even if that's not true?

It is at this point that a lot of programmers would decide to tack another number on there. So they'd release a 0.98.1 and a 0.98.2 and so on, giving them more breathing room before they hit that all-meaningful 1.00. Sometimes little suffixes make there way in there too, like when you have 0.98.1 and it turns out there is a bad bug in it that you discover pretty soon after releasing it, so you issue a new version which is basically the same as 0.98.1 but with that one bug patched. This change is so minor that you don't want to bump the version number up to 0.98.2 (people might think there were more substantial changes if you did that?) so instead you add a little suffix, and now you have "0.98.1a". It's easy to see how crazy version numbers come into existence!

But there is no need for anything like that until you decide that you need it for some reason. At work I use a version of MSVC 2005 which is called "Version 8.0.50727.806 (QFE.050727-8000)", and it depends on a version of the .NET framework called "Version 2.0.50727", and I have an XDK installed which is "Version 2.0.6534.3". Microsoft needs these ridiculous naming conventions because their software is huge and complex and is distributed through many different channels in many different packages, and because its built by humongously complex automated systems and because its built from many hundreds of complex pieces which are each themselves worked on by many programmers. So they need numbers like "8.0.50727.806" for lots of reasons. One of them is so that when they get bug reports they can figure out where to get the source code and executables of that version so that they can test and reproduce and fix the bug.

Anyway, for a project with just a few programmers (or just one), a major and minor version number should be totally sufficient.

[Ovyron]

Maybe you can go 0.001, 0.002 etc. so you get x10 as much space

I like the idea of dates better, for simplicity.

[Carey]

I support the date idea!

For most cases, I think a simple major.minor works fine. Especially when the minor number isn't limited to just a single digit.

What I dislike is when they mark a minor update 10 with the number 10, because in math: 1.1 = 1.10, so the versions:

1.0 - 1.1 - 1.2 - 1.3 - 1.4 - 1.5 - 1.6 - 1.7 - 1.8 - 1.9 - 1.10

Looks confusing (as if after 1.9 you go back to 1.1, because 1.10 looks a lot like 1.1.0)

So, I suggest to just avoid that. (You could go to letters, like 1.A, or 1.9a or something like that.)

But version numbering isn't math. There is absolutely no reason to think a version number couldn't have .10

You (and many others) dislike it simply becuase you expect the minor number to have only a single digit. You expect it to be math.

Which is a valid reason not to use, of course. If you don't like it (for any reason), then that is certainly a good reason.

You could change the decimal point to 'r'. That way you could have 9r15 instead of 9.15




I guess this whole discussion depends a lot on what he is actually wanting to do. Is this versioning for his internal private use, or for release.

He doesn't have to use the same numbering scheme for both. He can use whatever is most convenient or comfortable for each.


For internal use, a simple incrementing number would be okay.

As would doing several subminor numbers.

Using CVS or SVN/Subversion numbering schemes would also be a reasonable idea. In fact, if you do that kind of source control, you don't really need a seperate versioning number system to tack onto your builds.

Using something like 'TortiseSVN (for windows) works pretty easy and is a nice way to keep track of all your source code. It's really nice to have all your source in one place, along with comments about what is different about this version, or why you decided to rejeect the most recent build and go back to a previous version of the source, and so on.

I've never really been a big fan of CVS or SVN for personal use. I liked the idea, but hated the tools. Things like TortiseSVN make it actually easy enough to use. (There are other tools, of course. It's a matter of personal preference.)


For external use, a date based version number would work quite well. Just the year & month would be convenient, simple, and descriptive. With a subminor number if necessary.

[Ovyron]

You (and many others) dislike it simply becuase you expect the minor number to have only a single digit.

I think it looks better with one digit. But what about roman numerals? I don't think that they have been used before so it may be original.

I.i - I.ii - I.iii - I.iv - I.v - I.vii - I.viii - I.ix - I.x etc. (Zappa Mexico used the numeral II, for instance.)

[Carey]

You (and many others) dislike it simply becuase you expect the minor number to have only a single digit.

I think it looks better with one digit.

I used to be that way, but it just got too inconvenient. That's also one of the reasons I sometimes don't use a decimal point and instead use 123b45 or such. That way I don't have to deal with thinking of the numbers as the fractional part of the number.

But what about roman numerals? I don't think that they have been used before so it may be original.

I.i - I.ii - I.iii - I.iv - I.v - I.vii - I.viii - I.ix - I.x etc. (Zappa Mexico used the numeral II, for instance.)

I hadn't thought of that.

Sure, go ahead and use Roman numberals. It'd make sorting hard, though. And you can't do 0.3 in roman numbers, since they had no concept of 0.

You could even use Base-13. (Side reference to Douglas Adams & the answer of Life, the Universe and Everything being 42...)

Maybe binary would be a better choice, since we programmers are supposed to be able to think in binary...

Octal, perhaps? As a homage to the old chess programming days where they used octal more than binary or hexadecimal? (Octal was more common in the old days because the computers often had a multple of 6 bits, rather than 8 bits. Therefor octal was more appropriate than hexadecimal.)


None of those ideas sound as amusing as your Roman Numerals idea...(grin)

[Harald]

Chess engine versions a1, ..., a8, b1, ..., b8, ..., h1, ..., h8, Pa1, ..., Kh8