This is toward the end of the page (seems that they're still making major changes, but not breaking backwards compatability. Looks like 1.0 will mostly lock down new features):

"After 0.12, the next major stable release will be 1.0. At that point, very little will change in terms of the day-to-day operation of the project, but it will mark a significant milestone in terms of our stability and willingness to add new features. However, we've already gotten strict about maintaining backwards compatibility, so this won't really be so much of a shift. "

Version numbers aren't like numbers. Don't read the . as "point". It's "major dot minor dot release". There's no reason to increment the major version just if the minor version happens to coincide with the number base we use. That's for versions with backwards compatibility breaks (apart from 1.0, which defines the stable public API). See http://semver.org/.

They are actually using meaningful numbers. 1.x generally describes maturity. More so it means the software toolkit is, for the most part, stable and ready for the real world. Since version numbering in the closed source world generally helps sell products it's nice to see an open source project act as it should where the first number after the point increments as features are added and the second number with an optional second point reflects bug fixes and patches. It's a big deal when a version hits 1.x. A project like node.js doesn't have to pander to the masses like mozilla did with the firefox so called pseudo psychological numbering scheme.

Rake, for example, was perpetually stuck in the 0.x version because the author just mentally mapped the "0." part away. It recently moved to version 10.x :)

This is a better version of my question. Why use dot decimal notation unless just a fun way to model versions after network addresses