Software actually has three “versions” if you want to look at it that way. There is a MAJOR version, MINOR version and BUILD version. Using Blender as an example (and this is NOT anywhere near correctly accurate because I’m not even in the same country where the development is taking place!), we will take version 2.23:
2 - MAJOR version. This is the “major” enhancements indicator. They may add something significant like “twenty light types, built-in PHP code editor and numerous speed enhancements” and call this version 3.xx.
.23 - MINOR version. This is the “small” enhancements and “bug fixes” release indicator. A small enhancement to a feature that alread exists may be added, like better IPO editing, constraints, better booleans. Also, these MINOR releases include many bug fixes.
(xxx) - BUILD version. Blender does not include the build version (that I can find) but this is the count of all complete builds to the application. It is sort of a running total.
Pretend Blender was actually version 2.23.1000. The next release may not even get a bump in MAJOR or MINOR versions if it only fixed something like a misspelled word or something. The new version would be 2.23.1001. Now assume Blender gets an additional IPO called “ghost image” and the Blender release is then 2.24.1002. Finally, lets say Blender adds a whole new section for web site image deployment to popular art galleries around the 'net. It might be version 3.00.1003. See how the build number is CUMULATIVE, but the others are not.
Bottom line, a software company releaseing a MINOR version update is changing the x.MINOR.xxx version. MAJOR releases are MAJOR.xx.xxxx.
Does that help?
Thanx,
Matt
Director of Programming