version 1.2.3
polycounter lvl 18
How do version numbers for software or builds work? Is there a universal way of doing them or are there many ways of using them?
I had been working on a boardgame in my spare time called JIZZ WIZARDS! using a pbwiki, and have been using a version number for updates. How it works is, version 1.0 is reserved for when I would consider it complete, the first prototype or draft of the game marked version 0.1 and after every "update session" for the rules, I'd add a tenth, to 0.2, then 0.3 and so on. I'm curently at 0.6 and when I get time will be updating the rules to 0.7. I have a feeling I'll need more than 3 more iterations on my rules before I'd consider it version 1.0. The purpose of the version control is semi helpful, it helps track the progress of my rules and helps better communicate changes by placing them into a numeral category. I have a feeling I'm using it different than how they are supposed to be used. This all made me wonder, "How are they used?" I've seen version and build numbers with more breaks, like v1.23.4 and some with letters and shit, so yeah, I was looking for some insight and see what's out there.
-kp
I had been working on a boardgame in my spare time called JIZZ WIZARDS! using a pbwiki, and have been using a version number for updates. How it works is, version 1.0 is reserved for when I would consider it complete, the first prototype or draft of the game marked version 0.1 and after every "update session" for the rules, I'd add a tenth, to 0.2, then 0.3 and so on. I'm curently at 0.6 and when I get time will be updating the rules to 0.7. I have a feeling I'll need more than 3 more iterations on my rules before I'd consider it version 1.0. The purpose of the version control is semi helpful, it helps track the progress of my rules and helps better communicate changes by placing them into a numeral category. I have a feeling I'm using it different than how they are supposed to be used. This all made me wonder, "How are they used?" I've seen version and build numbers with more breaks, like v1.23.4 and some with letters and shit, so yeah, I was looking for some insight and see what's out there.
-kp
Replies
it has to work for you and for no one else
some people have intern and extern version numbers..
you could also mark pre release version numbers with an "i" for example ..
but it doesn't really matter.
Whole-number (x.) releases are usually substantial revisions (hence why companies like Autodesk have switched to a yearly name, instead of version number), and often break backwards compatibility. .x releases are usually more incremental, and are pretty open in what they contain. After that are usually bug fix releases.
Big software usually has very long version numbers usually, that include build numbers, etc. The specifics are, AFAIK, internal and not really important to users (or devs except in the case of debugging, for example). It is very difficult for version numbers to work out "correctly", and not really important- just document your changes and number how you think works.
Going from version 1.0 to version 2.0 is a brand spanking new version that excites the user with tons of new features, a new look, etc...
Going from 2.0 to 2.1 is a major bug fix or adding a new feature that is useful.
Going from 2.1 to 2.11 is like a tiny little overlooked flaw that got fixed. Fix enough tiny flaws and add some feature that makes things better and you've earned the right to go to 2.2
Make someone jizz their pants with a new prettier fun look, a whole slew of upgrades and features and you've earned the right to 3.0
I really don't know what I'm talking about...