3 ms·

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

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 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?

seiji 11y ago
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.

seiji 11y ago

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.