I understand that. But in my understanding a version number also reflects where a project stands in respect to features planned vs features implemented. Jumping from 0.x to 4.x is plain weird in this regard.
There are different philosophies of versioning, and version numbers may have different meanings depending on project/product.
io.js uses Semantic Versioning (semver) which has clear definitions of what version numbers mean; node.js previously has not; going to 4.0 when the fork is remerged is consistent with the semantic versioning of io.js, and since node.js versioning has no clear semantics prior to the merge, not inconsistent with node.js versioning. So it seems likely to be a reasonable numbering in context, even if its odd if you look at it only from the node.js side of the fork.
Technically node.js has been using semver—the semver spec says `0.*` is pre-release and anything goes. Since node.js is still 0.12 it's covered under that part of the semver spec (not a super useful part of the spec, but it doesn't actually violate semver).
But in my understanding a version number also reflects where a project stands in respect to features planned vs features implemented.
Nope. Version numbers are completely arbitrary. Firefox is on version 39 and Chrome is on 46.0.2471.2 and Safari is on version 8.0.6 and Webkit is on version 10600.6.3.
Windows 3.1 was followed by Windows 95 was followed by Windows 2000 was followed by Windows 7 was followed by Windows 10?
It is worth noting that Windows also maintains an internal version that is only visible through the `winver` command (the NT version).
Windows XP: 5.1
Windows Vista: 6.0
Windows 7: 6.1
Windows 8: 6.2
Windows 8.1: 6.3
Windows 10: 10.0 <-- New!
Interestingly, they also bumped the internal version to 10.0 in Windows 10. It was actually 6.4 in the early preview releases, but soon became 10.0. I find it intriguing considering Microsoft's conservative notion on backward compatibility, but even Microsoft seems to have finally reached the point of refreshing a version number.
In Windows 8.1, the GetVersion(Ex) APIs were deprecated. That means that while you can still call the APIs, if your app does not specifically target Windows 8.1, you will get Windows 8 versioning (6.2.0.0).
Microsoft didn't want to relive the hassle of Vista's major version bump. Thanks to the deprecation of the GetVersion APIs, however, programs will think they are on Windows 8 unless they explicitly opt-in to new version behavior. This meant Windows 10 could actually use the 10.0 version number without breaking stuff again.
> I find it intriguing considering Microsoft's conservative notion on backward compatibility, but even Microsoft seems to have finally reached the point of refreshing a version number.
Alternatively that bump could be caused by a request from a marketing manager
Hell, TeX version numbers are just additional digits of pi (latest version is 3.14159265), and Slackware jumped version numbers from 4 to 7 because people kept thinking it lagged behind Debian's whole-number versioning (ultimately, Slackware's version numbers would have surpassed Debian's even without the artificial bump, but whatever). Arbitrary indeed.
As a mathematician, I prefer the expression "converging towards perfection" :-)
More seriously, might be a urban legend, but I was once told that upon Knuth's death, the TeX code will be frozen and all remaining bugs will be permanently declared 'features'.
But in my understanding a version number also reflects where a project stands in respect to features planned vs features implemented.
Nope. Version numbers are completely arbitrary.
These are both slightly less than correct (but not wrong). Version numbers are completely arbitrary, from a totally objective standpoint. In this case, however, they are not. Semantic versioning defines guidelines for when to bump a given part of the version number, and gives meaning to each part of the version number. io.js follows semantic versioning, and when they merge into Node.js it will carry with it the new versioning scheme, which pretty much everyone agrees is a way better approach to versioning than Node's current way of doing things. You can read more about it at http://semver.org. Version numbers typically (in my experience, anyway) do not reflect future features, or features planned. They are representative of what exists in the codebase as of that given moment. Not sure where you heard that, but I'd be interested to hear about it. Also not sure why one would care about "features planned" in the current release of their software. Why tease me with what's to come when I can't even use it yet?
semver is interesting because it's part of the GitHub Re-Architect Software Development Initiative.
When GitHub was new, the founders dumped dozens of utilities and methodologies for public-facing software development on the world (smver, README-first development, mustache (was that them?), an RPC system inspired by Erlang, and dozens more) and a lot of people glommed on to many of those as The Holy Way, but everything is still just made up. (This is where the "Science" part of Computer Science falls short.)
Much like how Heroku proffers 12-factor apps because it fits their own narrative nicely, and it's also useful outside of Heroku, but just because one way of doing something exists doesn't mean it's necessarily the only or best way.
And, as far as version numbers go, with C libraries we have the concept of a "library version" and a "ABI version" — you increase the library version with any changes, but only the ABI version with breaking changes. It confuses some people to have one library with two version numbers, but it kinda makes sense too. It directly tells you the least common denominator of features this library can provide regardless of bug fixes or new features added later.
