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

In version v1.9.0.1: This is the explicit versioning scheme used when you don't want to use name for the pre-releases or build like -alpha,-beta.

1:Major version which might break the backward compatibility

9:Adding of new features to support you app along with backwards compatibility with previous version.

0:Some minor bug-fixes

1:Build number(Pre-release number)

but nowadays,you won't find such versioning scheme.Do refer Semantic Versioning [semver2.0] https://semver.org/

Answer 2

In version 1.9.0.1:

• 1: Major revision (new UI, lots of new features, conceptual change, etc.)

• 9: Minor revision (maybe a change to a search box, 1 feature added, collection of bug fixes)

• 0: Bug fix release

• 1: Build number (if used)—that's why you see the .NET framework using something like 2.0.4.2709

You won't find a lot of apps going down to four levels, 3 is usually sufficient.

Answer 3

It can be very arbitrary, and differs from product to product. For example, with the Ubuntu distribution, 8.04 refers to 2008.April

Typically the left most (major) numbers indicate a major release, and the further you go to the right, the smaller the change involved.

Answer 4

The paradigm of major release.minor release.bug fix is pretty common, I think.

In some enterprise support contracts there is $$$ (or breach of contract liability) associated with how a particular release is designated. A contract, for example, might entitle a customer to some number of major releases in a period of time, or promise that there will be fewer than x number of minor releases in a period, or that support will continue to be available for so many releases. Of course no matter how many words are put in to the contract to explain what a major release is versus a minor release, it is always subjective and there will always be gray areas – leading to the possibility that the software vendor can game the system to beat such contractual provisions.