Suppose we have program with a version number of 1.5.92:
The first number (1) represents the “major” version number. Normally these are only updated if there has been lots of major changes to a program.
The next number (5) represents a “minor” update. Maybe a feature or two was added to the program, but the overall program remained the same.
The third number (92) represents a bug fix. Our example shows that version 1.5.92 has had 92 bug fixes so far.
Suppose we have a software version like 22.214.171.124 then
the 1st no. denotes Kernel Version
the 2nd no. denotes Major Revision
the 3rd no. denotes Minor Revision
the 4th no. denotes Bug Fixes / Security Patches
Here, the even Kernel revision numbers corresponds to stable kernel releases and the odd Kernel revision numbers corresponds to unstable releases (under development).
Other schemes impart meaning on individual sequences:
In these examples, the definition of what constitutes a "major" as opposed to a "minor" change is entirely arbitrary and up to the author, as is what defines a "build", or how a "revision" differs from a "minor" change.
Some programs use letters rather than numbers, especially for minor update and bug fixes.
A similar problem of relative change significance and versioning nomenclature exists in book publishing, where edition numbers or names can be chosen based on varying criteria.It’s open to interpretation by the programmer or the marketing department as to whether the current update constitutes a major version change or just a minor enhancement.
In most proprietary software, the first released version of a software product has version 1.