Trevor Norris informed me that C++11 must be supported for the version of v8 that iojs ships with, which means node native module authors can use C++11. The native stream stuff looks neat, too. As an author of a node native add on, I look forward to this iojs/node fork stuff being resolved, so that I can start using new features. Until then, I refuse to make drop support for node.js.
In Google's defence - they have stated they won't support versions of v8 that reached end of life and have announced they're supporting io.js in favor of node. I totally get why Google won't backport fixes like this.
Google is actively helping io.js and development is coordinated.
To be clear, I find it annoying Google is not yet making the bug public even though the fix and test driver are available. Since they aren't going to patch the v8 in Node, I'd think Node users would really like to know if they are vulnerable to this and should manually patch it. stares at Joyent
Details about the rejectionUnhandled events dont seem to be in the docs yet, but this gist [1] explains it in detail. Looks like a decent solution to quiet suppression of unhandled rejections.
We're interested in feedback on how the event descriptions are phrased since there is some controversy regarding how these events "should be used" - if anyone has any feedback on phrasing or how to explain the usage of these events better I'd love to know how to improve them more.
Is this two releases in a row now that have had a major issue due to speed of release and lack of testing?
Seriously I think it is great to push the platform forward but this is exactly what Joyent was cautious about. Solves some bugs but creates other less predictable problems.
Current node-debugger still does not work with io.js so I am curious how the feature is debuggable.
Hang on - 1.3 was only about three days ago! Rapid progress is obviously fantastic, but is there a reason why these two releases weren't bundled together?
Great question. It started off as 1.3.x but ended up being 1.4 for semver issues. There was discussion[1] about this. In short - it was named 1.4 because of how NPM updated and because of the big features landing.
Not really unfortunate. Unlike with money, inflation of version numbers doesn't cause that much trouble. It just takes some getting used to. I've gotten used to the high version numbers in Chrome and Firefox, and I'm sure I'll get used to them in projects that use semver the right way as well.
Probably due to V8 upgrade which contains an embargoed fix. These are usually critical bugs that remain undisclosed until major users (read as: large companies) have patched their systems.
...the idea being that it's analogous to an uncaught exception bubbling up to the top and causing the process to crash, which is generally what you want to happen?
Yes, it's possible this indeed will be the default behavior at some later point.
Some people don't like this since `unhandledRejection`s can be handled later on at some point (for example, after a week of not adding a catch handler).
