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
the ones that vary less would be the first two, for major.minor, after that it can be anything from build, revision, release, to any custom algorithms (like in some MS products)
It depends, but the typical representation is that of major.minor.release.build.
Where:
So for instance, 1.9.0.1, means that it's version 1.9 of your software, following 1.8 and 1.7, etc. where 1.7, 1.8 and 1.9 all in some way typically add small amounts of new features alongside bugfixes. Since it's x.x.0.x, it's the initial release of 1.9, and it's the first build of that version.
You can also find good information on the Wikipedia article on the subject.
People don't always recognize the subtle difference between version numbers like 2.1, 2.0.1, or 2.10 - ask a technical support person how many times they've had trouble with this. Developers are detail oriented and familiar with hierarchical structures, so this is a blind spot for us.
If at all possible, expose a simpler version number to your customers.
In the case of a library, the version number tells you about the level of compatibility between two releases, and thus how difficult an upgrade will be.
A bug fix release needs to preserve binary, source, and serialization compatibility.
Minor releases mean different things to different projects, but usually they don't need to preserve source compatibility.
Major version numbers can break all three forms.
I wrote more about the rationale here.
version: v1.9.0.1
where-
. v is abbreviation of version. It varies with company to company depend on nomenclature adopted in his organisation. It may silent in some organisation like 1.9.0.1
. 1 indicates major version, will be updated on Architectural modification in application stacks, infrastructure (platform) or exposed networks interface
. 9 incates minor, will be updated on activity like adding new components like ui, api, database etc; under a specific architecture
. 0 indicates feature, will be updated on any enhancements on existing components (ui, api, database etc)
. 1 indicates build counter across all phase major, minor and feature. It also include hotfixes post production release.
Every organization/group has it's own standard. The important thing is that you stick to whatever notation you choose otherwise your customers will be confused. Having said that I've used normally 3 numbers:
x.yz.bbbbb. Where: x: is the major version (major new features) y: is the minor version number (small new features, small improvements without UI changes) z: is the service pack (basically the same as x.y but with some bug fixes bbbb: is the build number and only really visible from the "about box" with other details for customer support. bbbb is free format and every product can use it's own.