Major.Minor.Sub
Major corresponds to the PCB or product build.
Minor corresponds to the release number.
Sub corresponds to the release iterative release if the Minor number has been branched.
Major
So you are building a product. There will be 4-5 different prototype builds of the product before it hits production. The major number represents the prototype build the software will programmed on. This could be just for the PCB, or a prototype build of the enitre product. Usually these are a big deal, thus getting the major revision.
Minor
Minor is for subsequent software releases number after the build. So the third prototype build comes back with your software preprogrammed on it (version 3.0.0). Then you make more releases intended for this build (3.1.0, 3.2.0, 3.3.0) as development and testing continues.
Sub
Sub is if you have to branch a minor release to keep the software stable if there are any major features to be added between minor releases. Ie 3.1.1, 3.1.2, 3.1.3 gets released for tester to regress bugs, while the code is taken apart and put together again for release 3.2.0. Then of course, all the xx.1 xx.2 and xx.3 changes will need to be merged in at some point.
Another way to describe this: Major subdivides the project by hardware build, Minor subdivides it by software releases, and sub allows a scheme to fix bugs and do sub releases to QA
Yes, this is very similar to regular software version numbering. But the major is associated with hardware platform.
Would everyone agree with this scheme? Probably not, and I think that is okay. You see, revision numbering isn't a one-size-fits-all system. It all depends on the end-user of the version number. Who will be using the version number, and what organiziation concepts they will expect of it. This isn't the same for every industry.
Okay, time for some rest.