versioning

[george]

does anyone know the "proper" method to version your programs? here is how i do it:

1.0
1.0.1 (small feature/adjustmnet)
1.1 (substantial update, or 1.09+1)

does anyone know a website about this topic? for example, i read some where that your public version number and internal version number should be different, among other things.

not a big deal, but i thought it could be beneficial for all of us to know how to do it "right."

thanks

[andyb]

I didn't realise there was a "right" or "wrong" way to do it. As long as it makes sense to whoever is using the version control methods, why does it matter how it's done?

[Nutter2000]

I don't think there's a proper method either.
I'm sure you could find some academic waffle stating what should or should not be done but in reality it just needs to be something meaning full to the developer.

I think that the reason that a public version is said it should be different from a private version is when it's a large project with various parts split off among different teams.
For example, Team A is working on the front end and user interface. Team B is working on the physics engine, Team C is working on the gfx engine, and so on. Obviously each of those teams will be working at a different pace to the others and so will need a different version number. You can end up with numbers like 1.05.34.23 etc where as the public number should be nice and simple for the publisher and user so they can be aware when there's a newer version and to differentiate between released versions.
There may be other reasons so I'll let someone else shoot me down, but in my experience that's the one I've come across most.

[Phil Newton]

I use two figures for my external version numbers. Two figures is reasonable, and "version 1.43" is nicer to read than "version 1.4.3.1234". Internally I use four numbers, which looks like [major].[minor].[revision].[build].

As everyone has said, I don't think there's a proper method. It's all down to personal preference. If you don't find using four numbers useful, then don't bother. I think there's enough things for an indie to worry about without wondering whether their version number should have four or three sections ;)

[Rainer Deyke]

I use major.minor.revision. The first public release is 1.0.0. Before 1.0.0, I increment the 'minor' for major milestones and 'revision' for everything else. Starting with 1.0.0, I increment 'revision' for bug fixes, 'minor' for new features, and 'major' when I add major new functionality or completely redo a large part of the project.

[Emmanuel]

I used to use a major.minor.micro version scheme for everything and found out it was overkill during development stages. Now I use a build number during development and then a version number when the product is released to the public.

[GBGames]

The Linux kernel uses your method. Right now the latest stable version of it is at version 2.6.9. Stable versions of the kernel are signified by an even minor number. So the last few stable kernels were 2.4, 2.2, and 2.0. Development is done on odd-numbered minor versions. So 2.7, 2.5, 2.3, etc.

And of course, minor fixes and changes are signified by the last number.

[Sillysoft]

I use [major].[minor]([mini if needed]). Thus I could have 1.2 or 1.21. The major benefit of doing it like this is that it's a simple floating point greater then test when comparing the current version against the most recent one for update checks. If you want to do that with x.y.z then it just complicates things since it is no longer a real number.

[Coyote]

I use [major] [minor] [revision] - but I have a multiplayer game. The rule is that a change to the revision number won't break multiplayer compatability, but a minor will. So version 1.0.2 will play with version 1.0.1 and 1.0.3, but not version 1.1.0

Now, Joe Player probably has no clue what those numbers mean, but it works for the internal logic.