Ok, let's talk about assembly versions.
Currently, Microsoft (and a Microsoft-stack developers) using four number version: Major.Minor.Build.Revision. The vast majority of questions are about Build or Revision components. If a Build is more or less clear, the implementation of a Revision differs from developer to developer. Usually, we say that Revision is a unique ID of version of our product, which will changes at each build, even if it's fix or used for debugging reason. But what if we'repartially wrong?..
Ok. Why we need to four-number formatting? Because it's about hierarchy: we use Major number for big changes and Minor for small and when we change the Major number, wezero out the Minor number, we increase Build number at every build and zero out it when Minor number changes. Of course, we can always increase the Build number (as Microsoft does in Windows) and/or increase (or use the date or compute hash for) the Revision. But then why we need a hierarchy? We can simple use Release.Build scheme and have giant version numbers like 37.17365 (hello to Google and Mozilla!). If we use four-number formatting,we must use hierarchy rule for all parts of version. For example: we use Major number for big changes and Minor for small, we increase Build number at every build with thesame [internal and external] functionality and zero out it when the Minor number changes, and we increase Revision numberat every successful build and zero out it when Build number changes (=we use Revision when we need release fix and zero out it in all other reasons). In pseudo-graphical it looks like Major → Minor → Build → Revision hierarchy. As the result, we have cute version like 1.2.345.6 where full version is a unique ID of version of our product. Good job, guys.
And what scheme you are using?