So the Node.js is dead now?
EDIT:
Downvotes ahoy.
Let's be honest here. Stable code (especially stable threaded code) requires QA time after adding new features. There are commits in this release which are less than 5 days old. 5 days is not enough time to shake out bugs.
Given that the developers are human, unit tests are incapable of finding all issues, and QA resources cost money, there is no way that this release could be considered to be stable.
A company would deploy this at their own risk, knowing that it's likely to have bugs which will have to be reported and fixed.
Not all companies can afford to take on that kind of risk, ergo a release like Node.js, which trails behind the bleeding edge of these technologies, makes sense to exist.
Rather broad statement, that. Care to qualify it?
I would also point out that the parent thread is good evidence. My point was that SemVer didn't save them from making a mistake, nor did the lack of SemVer save Underscore the other night. Volatility is what bit people.
Simply waiting between commits reduces the rate of change, but does not increase the thoroughness of QA. In terms of defects, a project with very good, careful QA (any remotely acceptable strategy for reducing defects) will be at an advantage at every rate of change to a project which is just people pushing to master.
Some forms of careful QA impose a lot of latency between the decision to change and the change actually hitting, but that doesn't necessarily imply a reduction in throughput of changes per unit time, and it isn't the time which is reducing the defects but what is being done with that time.
By establishing the mindset that what you are pushing into master will make its way into production, you look at things very differently, with a much more critical eye. There are waterfall designed systems that took years to develop that made it to production with bugs... is a bug that breaks things for 5 minutes worse than one that sits for months, or a security fix that isn't deployed and might be exploited because your review process takes weeks?
Node.js uses an old V8 version ( Google doesn't support it anymore, and they don't even apply security patches to it ) while io.js has the latest V8, plus all the security patches and bug fixes from the io.js codebase, that node.js does not have.
Same story with libuv, the "main" library under the hood.
( most of this explained in this podcast http://devchat.tv/js-jabber/147-jsj-io-js-with-isaac-schleut... )
If older === more stable, then I guess you should use the oldest version in everything. Makes no sense.
More importantly, has Google shown genuine interest in supporting embedding v8? Their last blog post about this was in 2012.
As for libuv, I would rather use a battle tested version, than stay on the bleeding edge. Threading is hard, and race conditions are rarely caught by tests. I'm happy to let others break their production and identify the regressions before I commit to it.
Wanting to use proven software has no relation to using the "oldest" version. As software is used, bugs are found. The longer you wait to transition to using new features, the fewer bugs you will encounter when you make the transition. What's nonsensical about that?
[1] https://groups.google.com/d/msg/v8-users/UUyavs0KtwE/dhh4F8c...
When Joyent or other enterprisey Node users mean "stable" they mean it in the same sense as Windows XP is "stable". It means you have a bunch of dependencies designed to work with a specific version, and you don't want to do the work of migrating because you have bigger cheques to cash. Stable doesn't mean less features, less bugs, or a slower release pace. Those things just fall out as consequences.
This is also the essence of why io.js happened in the first place. The intened audiences are completely different.