Just to add to this list, a common method is "semantic versioning". There's a Wikipedia article explaining it which is worth reading. It's widely used where multiple components and dependencies are involved.

Another method (used by Microsoft) is Major.Minor.dateA.dateB. The build date and time is encoded in the last two fields. When a new version is built to fix a bug it automatically gets a version number higher than the previous version of the same component. Typically the combination of major and minor version determine compatibility.

And of course there's marketing versioning: 3, 3.1, 95, 98, NT, 2000, XP, 7, 8, 8.1, 10... whatever will sell a new version of your product.

Moving toward aerospace:

Spitfire Mk 1 to Mk IX...

Saturn ... Saturn 5

Soyuz 1..n, Apollo 1 .. 17 etc.

(Arguably these are mission names aa much as spacecraft versions)

Just to add to this list, a common method is "semantic versioning". There's a Wikipedia article explaining it which is worth reading. It's widely used where multiple components and dependencies are involved.

Another method (used by Microsoft) is Major.Minor.dateA.dateB. The build date and time is encoded in the last two fields. When a new version is built to fix a bug it automatically gets a version number higher than the previous version of the same component. Typically the combination of major and minor version determine compatibility.

And of course there's marketing versioning: 3, 3.1, 95, 98, NT, 2000, XP, 7, 8, 8.1, 10... whatever will sell a new version of your product.

Moving toward aerospace:

Spitfire Mk 1 to Mk IX...

Saturn ... Saturn 5

Soyuz 1..n, Apollo 1 .. 17 etc.

(Arguably these are mission names aa much as spacecraft versions)

Just to add to this list, a common method is "semantic versioning". There's a Wikipedia article explaining it which is worth reading. It's widely used where multiple components and dependencies are involved.

Another method (used by Microsoft) is Major.Minor.dateA.dateB. The build date and time is encoded in the last two fields. When a new version is built to fix a bug it automatically gets a version number higher than the previous version of the same component. Typically the combination of major and minor version determine compatibility.

And of course there's marketing versioning: 3, 3.1, 95, 98, NT, 2000, XP, 7, 8, 8.1, 10... whatever will sell a new version of your product.

Moving toward aerospace:

Spitfire Mk 1 to Mk IX...

Saturn ... Saturn 5

Soyuz 1..n, Apollo 1 .. 17 etc.

(Arguably these are mission names aa much as spacecraft versions)

Just to add to this list, a common method is "semantic versioning". There's a Wikipedia article explaining it which is worth reading. It's widely used where multiple components and dependencies are involved.

Another method (used by Microsoft) is Major.Minor.dateA.dateB. The build date and time is encoded in the last two fields. When a new version is built to fix a bug it automatically gets a version number higher than the previous version of the same component. Typically the combination of major and minor version determine compatibility.

And of course there's marketing versioning: 3, 3.1, 95, 98, NT, 2000, XP, 7, 8, 8.1, 10... whatever will sell a new version of your product.

Moving toward aerospace:

Spitfire Mk 1 to Mk IX...

Saturn ... Saturn 5

Soyuz 1..n, Apollo 1 .. 17 etc.

(Arguably these are mission names aa much as spacecraft versions)