Software versioning, what to use?

[paul_nicholls]

Hi all,
I am now thinking of giving my game "Day Of Destruction!" some sort of version "numbering", to help with updates - I am planning on releasing just the .pak and .exe files when I do updates if you have already downloaded the full game, so I will need to match versions.

I don't know where I should begin with version 'numbers', or even what version format I should go with...

Any ideas?

cheers,
Paul

[deathshadow]

There are so many ways of numbering software. Usually I try to avoid things like mozilla's infamous 2.0.0.14 build 285 since it's just getting too complex for it's own good.

I like to use a majorversion where 'appropriate' - aka alpha/beta/rc are 0.x, final is 1.x, only go to 2.x if major rewrites are done/major functionality changes.

For me the 'tell' is the minorversion - Best way I've found is to just use the build date in days since the day you started the project (or started counting)

So for example, if I started writing a program back on jan 1, a version build for distribution today would be 1.355 - and unlike some other numbering schemes, I do use leading zero's to pad out the version number.

It's simple, and leaves little doubt as to what version you are looking at.

[paul_nicholls]

There are so many ways of numbering software. Usually I try to avoid things like mozilla's infamous 2.0.0.14 build 285 since it's just getting too complex for it's own good.

I like to use a majorversion where 'appropriate' - aka alpha/beta/rc are 0.x, final is 1.x, only go to 2.x if major rewrites are done/major functionality changes.

For me the 'tell' is the minorversion - Best way I've found is to just use the build date in days since the day you started the project (or started counting)

So for example, if I started writing a program back on jan 1, a version build for distribution today would be 1.355 - and unlike some other numbering schemes, I do use leading zero's to pad out the version number.

It's simple, and leaves little doubt as to what version you are looking at.

ok...

So, in my case I started (coding) my game on Sun Jul 12 2009, and I am currently at SVN version 280.

I'm not sure what my version using your way would be...

cheers,
Paul

[dazappa]

There are so many ways of numbering software. Usually I try to avoid things like mozilla's infamous 2.0.0.14 build 285 since it's just getting too complex for it's own good.

I like to use a majorversion where 'appropriate' - aka alpha/beta/rc are 0.x, final is 1.x, only go to 2.x if major rewrites are done/major functionality changes.

For me the 'tell' is the minorversion - Best way I've found is to just use the build date in days since the day you started the project (or started counting)

So for example, if I started writing a program back on jan 1, a version build for distribution today would be 1.355 - and unlike some other numbering schemes, I do use leading zero's to pad out the version number.

It's simple, and leaves little doubt as to what version you are looking at.

ok...

So, in my case I started (coding) my game on Sun Jul 12 2009, and I am currently at SVN version 280.

I'm not sure what my version using your way would be...

cheers,
Paul

It really all depends on what you want... do you want to show random version numbers like 1.04 to people when they get updates? Usually I'll show people that number, and have a separate number that says what build it is that only my program knows...

Versioning is not something I see as very important. A simple integer like 5 or 27 to distinguish the versions of your various resources should be sufficient..

[NecroDOME]

You could use major version is the change is major (i.e. new content is required) and use minor version if you only fixed bugs.
1.0 = first release
1.1 = bug fix #1
1.2 = bug fix #2 and #3
2.0 = Some bugs fixed and an extra feature

For internal use you can make a tag in your svn that says "Day of Destruction 1.1". Or you could say simply 1.0.280. But its up to you and more a matter of taste I guess.

[paul_nicholls]

You could use major version is the change is major (i.e. new content is required) and use minor version if you only fixed bugs.
1.0 = first release
1.1 = bug fix #1
1.2 = bug fix #2 and #3
2.0 = Some bugs fixed and an extra feature

For internal use you can make a tag in your svn that says "Day of Destruction 1.1". Or you could say simply 1.0.280. But its up to you and more a matter of taste I guess.

Thanks all, I think I might just go with version 1.0 for my initial release, and then follow what NecroDOME suggested

Thanks again to all who have replied

BTW, I suppose I'd have to remember to alter/increment my 'version numbers' manually...I'm expecting to

cheers,
Paul

[User137]

If i do versions to my programs it means

0.xxxx first tests in vague percentage value such as 0.31 would mean 31% of wanted features done. If i'd apply a minor fix it would only get increased to 0.311, even 0.3111. None can really tell value of each feature but it really doesn't make a difference.
1.0 first working version with most intended behavior done
1.xxx bug fixes
2.0 working version of majorly different application, expansion pack or alike.

[paul_nicholls]

Yeah, I am now planning on doing it like this:

1.0.0 (competition release version - most features I planned)

<major change>.<minor change>.<bugfix>

Like, I'm planning to lower the volumn of all the sfx, especially the 'laser', so the next version should be:

1.1.0

thanks all!

cheers,
Paul

[arthurprs]

1.1.0

major version, version, minor version

major version = BIG changes
version = changes
minor version = bug fixes, adjustments

[paul_nicholls]

1.1.0

major version, version, minor version

major version = BIG changes
version = changes
minor version = bug fixes, adjustments

Thanks

cheers,
Paul