First, Blender proceeds at its own pace and time, totally independent of any other software package.
We use a v.r.i naming scheme, where v is the version, r is the revision, and i is the increment. Each node starts at 1 and counts up, but not necessarily in increments of 1. Presently, we have released the 45th revision to version 2 of Blender. In development, we are in the 16th increment toward the 46th revision to version 2.
The revision “numbering” depends soley on the project. For example my revisions usually get named MyFakeProgram revA, revB, revC. I’m almost positive though that if I did ever get hired for commercial work I’d have to use the numeric values instead. Also keep in mind that there may be revisions that are never given to the general user base. So it’s not uncommon to see a revision like Blender 2.45 followed by an official revision called blender 2.9.
Usually though, for simplistic reasons, the prog 1 prog 1.1 prog 1.2 is the way it goes.
On your last point, no Blender 8.00 will not be the same as 3dsmax8. What 3dsmax considers a large enough revision to call a new version, is likely not the same as what Blender considers a large enough change to call a new version. It just depends on the programmers and for commercial works, the advertising agents. Also, many software companies use a different version number for the public then they do to actually track their revisions. This is why Windows OS jumped from version 3.11 to version 95 in 2 years time. Windows 95 was basically version 4 of Windows, but the marketing folks thought Windows95 looked better. Of course this was a bit stupid when it was released in 1996 LOL. Also, don’t forget that some software doesn’t even attempt to tell the user anything with the version. They instead use random words like Gold or Extreme to announce a new version.
As allready stated this is soley up to the developement team but a commonly used scheme is
where major version increments mean major changes to the underliing code base which imply incompatibility between the two versions.
minorversion increments mean new features and minor upgrades but most of the stuff is compatible to the version before that meaning the programming API is kept stable.
microversion increments are bug fixes only no new features.
Another common scheme is to use the second number as an indication of stability all even numbers are stable releases while all odd numbers are developement releases which are not considered stable enough for production. This is used on the Linux Kernel as far as I know and by the Gimp project. The microversion is for bugfixes and the major number indicates major changes in the underliing codebase.
Btw the version 1.0 is considered the first version where all features the developer wanted to put into the programm are actually implemented in a stable manner. So it is actually possible for a stable program to never reach 1.0.
I would say it goes: generation.series, minor.increment (2.45.16 is 16th increment of 5th minor version of the 4x series of the 2.00 generation), which accounts for jumps like 1.80 to 2.00 (or was there a 1.90?) and 2.46 to 2.50.