Is there a general term to refer to what you might call the dot numbering system that computer systems use: Ubuntu 15.10.1 or Mac OSX 10.11.3?
One could call it "build versioning" but wouldn't that also apply to things like "Build 1922" (sequential) or "Build 20160121" (date based) or "Build 55azaw" (coded).
Best Answer
The version numbers of the format #.#.# are individually called MAJOR, MINOR, and PATCH as Simon points out. While this scheme originated for software, some has adapted it to version documents and hardware.
Yet they can be considered a Semantic Version.
By OP requset, I have included Semantic Versions as an asnwer.
I'll expand on what is Semantic Versioning, how it is used, and why I didn't consider it the answer.
Note: Version number is a more inclusive term.
Semantic Versions
In semantic versioning, a number of the form MAJOR.MINOR.PATCH has a more specific meaning. As follows:
If the organization that develops the software respects semantic versioning, it indicates that you can always upgrade to a higher MINOR number. Upgrading to a higher MAJOR number may require to learn to use the new version, and may also require to upgrade other components of the system (and components that depend on the particular version of the software may stop working).
Quick guide to how to use semantic versions
This should NOT be considered a replacement for the semver specification.
Increase the MAJOR number when the new version is NOT a drop-in replacement for the old one. That is, when something possible with the old version of the software is no longer possible in the new one.
If the new version can do all that the old version can do, the MAJOR number must remain unchanged. This indicates that the new version can replace the old version in all cases.
Increase the MINOR number when the new version added new functionality. In that case it may not be safe to downgrade to the old version because some of the new functionality may be in use.
Increase the PATCH number when the new version has non-functional improvements such as:
new art work
increased performance
lower memory requirements
corrected behaviour on edge cases
removed glitchs
removed critical conditions (e.g. the app crashed)
removed race conditions (e.g. the app hangs unresponsive or otherwise stuck)
removed security vulnerabilities
etc...
Rule of thumb: on added support, increase the MINOR number. This way you communicate that downgrading may lead to compatibility problems. But, on removed support, increase the MAJOR number. This way you communicate that upgrading may lead to compatibility problems.
While it is true that - for an organization that uses semantic versioning - each build of a software will have a semantic version. The build version is only required to be unique, and it is expected to increase as builds go on.
Controversy
At the beginnings of software versioning, it was intended to allow to keep track of software packages, so people could know what version of the software are newer / better. From this perspective a change in the major number indicates a significant change in the code base. This is useful from the support and maintenance perspective.
Yet, once software packages started to encode dependencies on each other, version number checks were introduced to see if the installed version is compatible. Although, since the version numbers were intended to be human readable, no strict standard were in place on how to do that. This introduced some problems...
For instace, Windows 95 is version 4.0 (as it was a considerable change in the code base from Windows 3) but the API reports 3.95. The reason being that software often checked if the MAJOR number was at least 3 and the MINOR number was at least 10 (for example), so moving the minor number back to 0 would have made those software misbehave... and since the user changed the OS, but not the software, it is perceived that the the OS was at fault. If you upgrade your OS and software stop to work, what do you blame? Most people blame the OS.
Contrast with modern versions of Windows. Windows Vista version number is 6.0 - yet Windows 7 is actually 6.1. Windows 8 is 6.2 and Windows 8.1 is 6.3. This reflects the fact that from the API perspective these OS aren't much different. Windows 10 humorously is 10.0.
Another example from Microsoft is DirectX, I have DirectX 11.3. Yet that what it says to the humans, meanwhile it reports its version as 04.06.05. In fact, DirectX never went over the version 4.
Other companies have their own quirks, and having a different version to the shown to humans is not unique of Microsoft. For instance, Java 5 is actually Java 1.5.0, Java 6 is 1.6.0, and so on...
Different organization such as Apple, Apache, Debian, Gnu, Unicode has developed their own solutions to the versioning problem. For example Ubuntu bases the version numbers in the date of release.
This leads to the confusion of new developers, who don't really know how to set the version numbers of their software.
The SemVer specification was created in such way that software can easily move to use Semantic Versioning, as it is based on what many developer were already doing. it serves as a guide to developers, and can be used by package managers to check version compatibility.
With that said, SemVer is not enforced by any means. Many may claim and even attempt to use SemVer, yet humans err, and an inadecuate version number may see the light now and then.
Also, since the removal of a feature is a breaking change, for Semantic Versioning it implies to increase the version number, which may be perceived by the users as an improvement. The removal of a feature is often the opposite of that!
If the migration to the new version is expected to be difficult or the old and new version are expected to coexist, the new version can be considered a different package. This eases providing updates to the old version (for security fixes, for instance).
The idea of returning to human readable version numbers, where a higher number means "better" and the difference of the numbers suggest how different are the versions, has got the coined name of "Romantic Versioning".
Due to all the problems mentioned above, when you see #.#.# it doesn't imply Semantic Versioning. It may not be a semantic version, it may not be a version number at all! That's why I didn't think Semantic Version to be the answer.
The deeper question is why people started using MAJOR.MINOR.PATCH for software versions. I decided to post my Speculation on how version numbers came to be elsewhere.