+- MFGG Forums (https://forums.mfgg.net)
+-- Forum: MFGG (https://forums.mfgg.net/forumdisplay.php?fid=4)
+--- Forum: Developer Discussion (https://forums.mfgg.net/forumdisplay.php?fid=10)
+--- Thread: Version histories (/showthread.php?tid=1361)
Version histories - VinnyVideo - 10-11-2018
When you program games - or other projects - how do you use version numbers? Unless I'm working on a team that has a certain standard for this (and I haven't been on such a team before, even at work), here's what I do:
1.0 is a full release - it's a completely playable game that includes the basic functionality I planned to include, with no known game-breaking bugs.
For each future release, I'll increase the version number by either 0.1 or 0.01, depending on how big the update is and how many updates I anticipate making.
For pre-release demos, the first release is usually 0.1 no matter what. Otherwise, the version number is the project's estimated completion percentage. For example, if I think I'm about 50% done with the game, the version number will be 0.5. When game is nearly complete and I send a demo to my testing folks, it'll have a high number like 0.95.
I won't increase the version number by 1 unless I'm rewriting huge parts of the code or adding a massive amount of new functionality. For that reason, I haven't released a lot of 2.0's over the years.
That's the way I usually do things. Some people handle version numbers in a very different way, though (here's looking at you, Firefox and Chrome).
RE: Version histories - Mario - 10-11-2018
Anything that has a user API should use semver, but you can use it for a guideline for pretty much any kind of program
RE: Version histories - Q-Nova - 10-18-2018
I don't really use version numbers very often for my games, since I rarely update them after public release. In the Internet, the only stuff I updated was A Typical Day (since I wasn't really too happy with the initial release) and Quillax's NetKeen Levels (which mostly got expanded since I really enjoyed making NetKeen levels and wanted to make more at that time), with only the former using a version number, which was simply increased by 0.1 after the update.
The way I see version numbers is pretty much identical to VinnyVideo's view on them. Semantic Versioning seems pretty good, though.
RE: Version histories - Syaxamaphone - 10-19-2018
I don't have time for standards, I just add 0.1 like a scrub
RE: Version histories - Cruise Elroy - 10-20-2018
I've only used version numbers as an afterthought for when I need to fix any bugs in my games. I usually mark them as 1.0.x; I don't think I've ever gone up the 1.x scale.
The only time I haven't used a system like this is for my (now on hiatus (don't worry, it isn't cancelled!)) fan game, Pac-Man Megamix. The .exe files were each named in accordance to the month, day, and year that it was compiled (for example, a game made on October 10th, 2018 would be called pmm102018a.exe). If I needed to make more than one build in a day, I would change the letter a at the end (going with the previous example, a new build would be pmm102018b.exe).
This is likely only going to be for the private builds, though. If I get my game into the alpha stage, I'll probably look into a version number like 0.0.1 or Alpha 1.0.0.
RE: Version histories - Retriever II - 10-22-2018
The only game that was a big enough undertaking to version:
![[Image: J9PXqU0.png]](https://i.imgur.com/J9PXqU0.png)
I have no idea either.
RE: Version histories - starscratcher - 12-25-2018
For me it is:
{Major}.{Minor}.{Patch}.{Build}
Major is, well, a major update!
Minor is for small content or functionality updates / additions.
Patch is for bug-fixes, patches, etc. that do not bring new content with them.
And build increases every time a new build was made. It usually is 0 for a release, as a release should be at least a patch.
Also, if "minor" increases, everything after it will be set to 0, that's for everything tho.