What do the numbers in a version typically represent (i.e. v1.9.0.1)?

Question

Maybe this is a silly question, but I\'ve always assumed each number delineated by a period represented a single component of the software. If that\'s true, do they ever rep

Answer 1

Generally then number are in the format of version.major.minor.hotfix, not individual internal components. So v1.9.0.1 would be version 1, major release 9 (of v1), minor release (of v1.9) 0, hot fix 1 of (v1.9.0).

Answer 2

Usually its:

MajorVersion.MinorVersion.Revision.Build

Answer 3

Everyone chooses what they want to do with these numbers. I've been tempted to call releases a.b.c since it's rather silly anyway. That being said, what I've seen over the last 25+ years of development tends to work this way. Let's say your version number is 1.2.3.

The "1" indicates a "major" revision. Usually this is an initial release, a large feature set change or a rewrite of significant portions of the code. Once the feature set is determined and at least partially implemented you go to the next number.

The "2" indicates a release within a series. Often we use this position to get caught up on features that didn't make it in the last major release. This position (2) almost always indicates a feature add, usually with bug fixes.

The "3" in most shops indicates a patch release/bug fix. Almost never, at least on the commercial side, does this indicate a significant feature add. If features show up in position 3 then it's probably because someone checked something in before we knew we had to do a bug fix release.

Beyond the "3" position? I have no clue why people do that sort of thing, it just gets more confusing.

Notably some of the OSS out there throws all this out of wack. For example, Trac version 10 is actually 0.10.X.X. I think a lot of folks in the OSS world either lack confidence or just don't want to announce that they have a major release done.

Answer 4

The first number is typically referred to as the major version number. It's basically used to denote significant changes between builds (i.e. when you add many new features, you increment the major version). Components with differing major versions from the same product probably aren't compatible.

The next number is the minor version number. It can represent some new features, or a number of bug fixes or small architecture changes. Components from the same product which differ by the minor version number may or may not work together and probably shouldn't.

The next is usually called the build number. This may be incremented daily, or with each "released" build, or with each build at all. There may be only small differences between two components who differ by only the build number and typically can work well together.

The final number is usually the revision number. Often times this is used by an automatic build process, or when you're making "one-off" throw-away builds for testing.

When you increment your version numbers is up to you, but they should always increment or stay the same. You can have all components share the same version number, or only increment the version number on changed components.

Answer 5

major.minor[.maintenance[.build]]

http://en.wikipedia.org/wiki/Software_versioning#Numeric

Answer 6

Major.minor.point.build usually. Major and minor are self-explanatory, point is a release for a few minor bugfixes, and build is just a build identifier.