2013.03.28, Version 0.11.0 (Unstable)
V8: update to 3.17.13
os: use %SystemRoot% or %windir% in os.tmpdir() (Suwon Chae)
util: fix util.inspect() line width calculation (Marcin Kostrzewa)
buffer: remove _charsWritten (Trevor Norris)
fs: uv_[fl]stat now reports subsecond resolution (Timothy J Fontaine)
fs: Throw if error raised and missing callback (bnoordhuis)
tls: expose SSL_CTX_set_timeout via tls.createServer (Manav Rathi)
tls: remove harmful unnecessary bounds checking (Marcel Laverdet)
buffer: write ascii strings using WriteOneByte (Trevor Norris)
dtrace: fix generation of v8 constants on freebsd (Fedor Indutny)
dtrace: x64 ustack helper (Fedor Indutny)
readline: handle wide characters properly (Nao Iizuka)
repl: Use a domain to catch async errors safely (isaacs)
repl: emit 'reset' event when context is reset (Sami Samhuri)
inspect()method may return an Object (Nathan Rajlich)
console.dir()bypasses inspect() methods (Nathan Rajlich)
Source Code: http://nodejs.org/dist/v0.11.0/node-v0.11.0.tar.gz
Macintosh Installer (Universal): http://nodejs.org/dist/v0.11.0/node-v0.11.0.pkg
Windows Installer: http://nodejs.org/dist/v0.11.0/node-v0.11.0-x86.msi
Windows x64 Installer: http://nodejs.org/dist/v0.11.0/x64/node-v0.11.0-x64.msi
Windows x64 Files: http://nodejs.org/dist/v0.11.0/x64/
Linux 32-bit Binary: http://nodejs.org/dist/v0.11.0/node-v0.11.0-linux-x86.tar.gz
Linux 64-bit Binary: http://nodejs.org/dist/v0.11.0/node-v0.11.0-linux-x64.tar.gz
Solaris 32-bit Binary: http://nodejs.org/dist/v0.11.0/node-v0.11.0-sunos-x86.tar.gz
Solaris 64-bit Binary: http://nodejs.org/dist/v0.11.0/node-v0.11.0-sunos-x64.tar.gz
Other release files: http://nodejs.org/dist/v0.11.0/
4889d63a4a08d146d59cd057b1c8b341ceac07cf node-v0.11.0-darwin-x64.tar.gz 4ef64fa36c095edfa3c6da852ed1ec46c6f3cf23 node-v0.11.0-darwin-x86.tar.gz 04c4d1fb71f98dfc921d9558667a727ca1aa6586 node-v0.11.0-linux-x64.tar.gz b1507837292e23464e2d184007f2567db3db1483 node-v0.11.0-linux-x86.tar.gz cd195da08ea5208a6c08b95511fa888d750f4cd7 node-v0.11.0-sunos-x64.tar.gz 4698b9a6cb911cbea3deac38ea191cef3051b3ab node-v0.11.0-sunos-x86.tar.gz 829649fe65133459c7fc231b8d048f19ae870c7b node-v0.11.0-x86.msi 7958b8212aaa9787724c552197d37cf5602ff645 node-v0.11.0.pkg 0402aae18f847238409e9d1a5ddd806beb5fe678 node-v0.11.0.tar.gz 320778de3329437815daa4f86d1a89db33458126 node.exe 1f4f509a9dc48c519064ca7f2deddeaff2b6b15b node.exp 5f83864acae194c0652a61af71262bd1ba55a04c node.lib 0d100a18ba569e5e9bb9e216355959261c4cd77b node.pdb b55553c83e12f253f23dec4d998b05bd673db83b x64/node-v0.11.0-x64.msi 7100ef58f9a8428d2bdd9d4de8ffb679d0198b1e x64/node.exe 12bf810852e7097bde1bf4bff6cd7f802603cdb9 x64/node.exp 28f83178241353dc727ba6d8ff38f9b9177be79a x64/node.lib 6c0f43db501facc3d9ed542a090f9ba2e84bdc41 x64/node.pdb
2013.03.28, Version 0.10.2 (Stable)
npm: Upgrade to 1.2.15
uv: Upgrade to 0.10.3
tls: handle SSL_ERROR_ZERO_RETURN (Fedor Indutny)
tls: handle errors before calling C++ methods (Fedor Indutny)
tls: remove harmful unnecessary bounds checking (Marcel Laverdet)
crypto: make getCiphers() return non-SSL ciphers (Ben Noordhuis)
crypto: check randomBytes() size argument (Ben Noordhuis)
timers: do not calculate Timeout._when property (Alexey Kupershtokh)
timers: fix off-by-one ms error (Alexey Kupershtokh)
timers: handle signed int32 overflow in enroll() (Fedor Indutny)
stream: Fix stall in Transform under very specific conditions (Gil Pedersen)
stream: Handle late 'readable' event listeners (isaacs)
stream: Fix early end in Writables on zero-length writes (isaacs)
domain: fix domain callback from MakeCallback (Trevor Norris)
child_process: don't emit same handle twice (Ben Noordhuis)
child_process: fix sending utf-8 to child process (Ben Noordhuis)
Source Code: http://nodejs.org/dist/v0.10.2/node-v0.10.2.tar.gz
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.2/node-v0.10.2.pkg
Windows Installer: http://nodejs.org/dist/v0.10.2/node-v0.10.2-x86.msi
Windows x64 Installer: http://nodejs.org/dist/v0.10.2/x64/node-v0.10.2-x64.msi
Windows x64 Files: http://nodejs.org/dist/v0.10.2/x64/
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.2/node-v0.10.2-linux-x86.tar.gz
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.2/node-v0.10.2-linux-x64.tar.gz
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.2/node-v0.10.2-sunos-x86.tar.gz
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.2/node-v0.10.2-sunos-x64.tar.gz
Other release files: http://nodejs.org/dist/v0.10.2/
860ed25d3e77d4676b5512f87f3f98b6783ee258 node-v0.10.2-darwin-x64.tar.gz 811eb3b66651dfffeaf928496e8eecab5c9304fb node-v0.10.2-darwin-x86.tar.gz 2914731bdbe809483ed9da2578ce19121494e437 node-v0.10.2-linux-x64.tar.gz dbf039ee15e423738db4ffc9c498d6b0ad54da07 node-v0.10.2-linux-x86.tar.gz 17bc5bf26af7da790e6b0c4cbb2b73ea1c9f2ed5 node-v0.10.2-sunos-x64.tar.gz 5e02e35cc15ae56953921ad4c8e45b849c736e20 node-v0.10.2-sunos-x86.tar.gz 2adb1bf5919fb8adeaf96edd8a8ed16d71a3f8f8 node-v0.10.2-x86.msi 73ff97a4d2d3bb1f468db2654b5b59a28f868cce node-v0.10.2.pkg 759a05eff48ff0b54e55748012c5c45502f7cecd node-v0.10.2.tar.gz 6c1336a61395747fed20a12c8977a2b2ecf23354 node.exe f0775d4f649ee9c3d5614fdb26e64bc7d000cd5d node.exp 9860c6eb9062fbdc50b515f4ccab179f74dd3ec8 node.lib d41d99a3921022533c1760e15447ce3acf050a7d node.pdb 1dbd11a5278831356daca035fe5bbbe1062798b4 x64/node-v0.10.2-x64.msi d36abd4ecf02c522e8c75fce24eab1ce800d6458 x64/node.exe 295a950fe3c1c3ceb04249474388b891bf2a39ed x64/node.exp b64eabafc3f9498552b3ea97bd0d922db1f90f75 x64/node.lib 1f31d6c0079e9f2c9a6de3d956649d83ca6e7a25 x64/node.pdb
2013.03.21, Version 0.10.1 (Stable)
npm: upgrade to 1.2.15
crypto: Improve performance of non-stream APIs (Fedor Indutny)
tls: always reset this.ssl.error after handling (Fedor Indutny)
tls: Prevent mid-stream hangs (Fedor Indutny, isaacs)
net: improve arbitrary tcp socket support (Ben Noordhuis)
net: handle 'finish' event only after 'connect' (Fedor Indutny)
http: Don't hot-path end() for large buffers (isaacs)
fs: Missing cb errors are deprecated, not a throw (isaacs)
fs: make write/appendFileSync correctly set file mode (Raymond Feng)
stream: Return self from readable.wrap (isaacs)
stream: Never call decoder.end() multiple times (Gil Pedersen)
windows: enable watching signals with process.on('SIGXYZ') (Bert Belder)
node: revert removal of MakeCallback (Trevor Norris)
node: Unwrap without aborting in handle fd getter (isaacs)
Source Code: http://nodejs.org/dist/v0.10.1/node-v0.10.1.tar.gz
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.1/node-v0.10.1.pkg
Windows Installer: http://nodejs.org/dist/v0.10.1/node-v0.10.1-x86.msi
Windows x64 Installer: http://nodejs.org/dist/v0.10.1/x64/node-v0.10.1-x64.msi
Windows x64 Files: http://nodejs.org/dist/v0.10.1/x64/
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.1/node-v0.10.1-linux-x86.tar.gz
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.1/node-v0.10.1-linux-x64.tar.gz
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.1/node-v0.10.1-sunos-x86.tar.gz
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.1/node-v0.10.1-sunos-x64.tar.gz
Other release files: http://nodejs.org/dist/v0.10.1/
e213170fe5ec7721b31149fba1a7a691c50b5379 node-v0.10.1-darwin-x64.tar.gz 5526d189fa3180e11731e1aebb0f22c1c2fb3d8d node-v0.10.1-darwin-x86.tar.gz ec0818d8f151d933ec79961374bf74d9855305a5 node-v0.10.1-linux-x64.tar.gz b6345e86bc52575f8cc275cda36b1295ed544139 node-v0.10.1-linux-x86.tar.gz e94cb3ab3ac5a8026564152798070e06f1ba3119 node-v0.10.1-sunos-x64.tar.gz a894eaca7f49077e48b1786071dbdf57a2ea704c node-v0.10.1-sunos-x86.tar.gz 3f64590730d8e24e57530192479fd39dafde13b5 node-v0.10.1-x86.msi b41c576c473a1ae44c3061fe4799362239f00d8f node-v0.10.1.pkg d4d9ef3b70452112246ea2043ef75943611e3537 node-v0.10.1.tar.gz c034695812148c3fafe8b208203355d16289d1a7 node.exe 9fac94cbe9431ca518fdb1eed1a1b240a58ac781 node.exp 3571d5d7f9940f48b75f9a9b1fac8c8661e8ace2 node.lib 74f9ea112e2da1c1837180422a20630bc92bd5c9 node.pdb 0958d68900b80419e2af7a5448c4a451af06d0b4 x64/node-v0.10.1-x64.msi cc074b6c99cb1df01707ea12e986cf5bb4dc3c05 x64/node.exe f2746fea78ffb346e8ea979ea09924dc4408bcb9 x64/node.exp 1f1d9d1ba0d9383ecc93e8d8a481b13db39dc5f8 x64/node.lib 39a0a5a699e4a8cba44e618f6be6bd79f36a370f x64/node.pdb
I am pleased to announce a new stable version of Node.
This branch brings significant improvements to many areas, with a focus on API polish, ease of use, and backwards compatibility.
For a very brief overview of the relevant API changes since v0.8, please see the API changes wiki page.
The changes to the stream interface have been a long time in the making. Even from the earliest days of Node, we've all sort of known that this whole "data events come right away" and "pause() is advisory" stuff was unnecessarily awful. In v0.10, we finally bit the bullet and committed to making drastic changes in order to make these things better.
More importantly, all streams in Node-core are built using the same set of easily-extended base classes, so their behavior is much more consistent, and it's easier than ever to create streaming interfaces in your own userland programs.
In fact, the Streams2 API was developed while using it for modules in the npm registry. At the time of this writing, 37 published Node modules already are using the readable-stream library as a dependency. The readable-stream npm package allows you to use the new Stream interface in your legacy v0.8 codebase.
Domains and Error Handling
domain module has been elevated from "Experimental" to
"Unstable" status. It's been given more of a first-class treatment
internally, making it easier to handle some of the edge cases that we
found using Domains for error handling in v0.8. Specifically, domain
error handler no longer relies on
being raised, and the C++ code in Node is domain-aware.
If you're not already using Domains to catch errors in your programs, and you've found yourself wishing that you could get better debugging information when errors are thrown (especially in the midst of lots of requests and asynchronous calls), then definitely check it out.
In v0.8 (and before), the
process.nextTick() function scheduled its
callback using a spinner on the event loop. This usually caused the
callback to be fired before any other I/O. However, it was not
As a result, a lot of programs (including some parts of Node's
internals) began using
process.nextTick as a "do later, but before
any actual I/O is performed" interface. Since it usually works that
way, it seemed fine.
However, under load, it's possible for a server to have a lot of I/O
scheduled, to the point where the
nextTick gets preempted for
something else. This led to some odd errors and race conditions,
which could not be fixed without changing the semantics of nextTick.
So, that's what we did. In v0.10,
nextTick handlers are run right
process.nextTick, then the callback will fire
as soon as the code runs to completion, but before going back to
the event loop. The race is over, and all is good.
However, there are programs out in the wild that use recursive calls
process.nextTick to avoid pre-empting the I/O event loop for
long-running jobs. In order to avoid breaking horribly right away,
Node will now print a deprecation warning, and ask you to use
setImmediate for these kinds of tasks instead.
Latency and Idle Garbage Collection
One of the toughest things to get right in a garbage collected language is garbage collection. In order to try to avoid excessive memory usage, Node used to try to tell V8 to collect some garbage whenever the event loop was idle.
However, knowing exactly when to do this is extremely difficult.
There are different degrees of "idleness", and if you get it wrong,
you can easily end up spending massive amounts of time collecting
garbage when you'd least expect. In practice, disabling the
IdleNotification call yields better performance without any
excessive memory usage, because V8 is pretty good at knowing when it's
the best time to run GC.
So, in v0.10, we just ripped that feature out. (According to another point of view, we fixed the bug that it was ever there in the first place.) As a result, latency is much more predictable and stable. You won't see a difference in the benchmarks as a result of this, but you'll probably find that your app's response times are more reliable.
Performance and Benchmarks
When the Streams2 feature first landed in master, it disrupted a lot of things. We focused first on correctness rather than speed, and as a result of that, we got a correct implementation that was significantly slower.
We have a consistent rule in Node, that it cannot be allowed to get slower for our main use cases. It took a lot of work, but over the last few months, we've managed to get v0.10 to an appropriate level of performance, without sacrificing the API goals that we had in mind.
Benchmarks are complicated beasts. Until this release, we've gotten by with a pretty ad-hoc approach to running benchmarks. However, as we started actually having to track down regressions, the need for a more comprehensive approach was obvious.
Work is underway to figure out the optimum way to get statistically significant benchmark results in an automated way. As it is, we're still seeing significant jitter in some of the data, so take the red and green colors with a grain of salt.
The benchmarks below were run on an Apple 13-inch, Late 2011 MacBook Pro with a 2.8 GHz Intel Core i7 processor, 8GB of 1333MHz DDR3 RAM, running OS X Lion 10.7.5 (11G63b). The numbers are slightly different on Linux and SmartOS, but the conclusions are the same. The raw data is available, as well.
Node is for websites, and websites run over HTTP, so this is the one that people usually care the most about:
http/cluster.js type=bytes length=4: v0.10: 16843 v0.8: 16202 ................. 3.96% http/cluster.js type=bytes length=1024: v0.10: 15505 v0.8: 15065 .............. 2.92% http/cluster.js type=bytes length=102400: v0.10: 1555.2 v0.8: 1566.3 ......... -0.71% http/cluster.js type=buffer length=4: v0.10: 15308 v0.8: 14763 ................ 3.69% http/cluster.js type=buffer length=1024: v0.10: 15039 v0.8: 14830 ............. 1.41% http/cluster.js type=buffer length=102400: v0.10: 7584.6 v0.8: 7433.6 ......... 2.03% http/simple.js type=bytes length=4: v0.10: 12343 v0.8: 11761 .................. 4.95% http/simple.js type=bytes length=1024: v0.10: 11051 v0.8: 10287 ............... 7.43% http/simple.js type=bytes length=102400: v0.10: 853.19 v0.8: 892.75 .......... -4.43% http/simple.js type=buffer length=4: v0.10: 11316 v0.8: 10728 ................. 5.48% http/simple.js type=buffer length=1024: v0.10: 11199 v0.8: 10429 .............. 7.38% http/simple.js type=buffer length=102400: v0.10: 4942.1 v0.8: 4822.9 .......... 2.47%
What we see here is that, overall, HTTP is faster. It's just slightly
slower (1-5%) when sending extremely large string messages (ie
type=bytes rather than
type=buffer). But otherwise, things are
about the same, or slightly faster.
The fs.ReadStream throughput is massively improved, and less affected by the chunk size argument:
fs/read-stream buf size=1024: v0.10: 1106.6 v0.8: 60.597 ................... 1726.12% fs/read-stream buf size=4096: v0.10: 1107.9 v0.8: 235.51 .................... 370.44% fs/read-stream buf size=65535: v0.10: 1108.2 v0.8: 966.84 .................... 14.62% fs/read-stream buf size=1048576: v0.10: 1103.3 v0.8: 959.66 .................. 14.97% fs/read-stream asc size=1024: v0.10: 1081.5 v0.8: 62.218 ................... 1638.21% fs/read-stream asc size=4096: v0.10: 1082.3 v0.8: 174.78 .................... 519.21% fs/read-stream asc size=65535: v0.10: 1083.9 v0.8: 627.91 .................... 72.62% fs/read-stream asc size=1048576: v0.10: 1083.2 v0.8: 627.49 .................. 72.62% fs/read-stream utf size=1024: v0.10: 46.553 v0.8: 16.944 .................... 174.74% fs/read-stream utf size=4096: v0.10: 46.585 v0.8: 32.933 ..................... 41.45% fs/read-stream utf size=65535: v0.10: 46.57 v0.8: 45.832 ...................... 1.61% fs/read-stream utf size=1048576: v0.10: 46.576 v0.8: 45.884 ................... 1.51%
The fs.WriteStream throughput increases considerably, for most workloads. As the size of the chunk goes up, the speed is limited by the underlying system and the cost of string conversion, so v0.8 and v0.10 converge. But for smaller chunk sizes (like you'd be more likely to see in real applications), v0.10 is a significant improvement.
fs/write-stream buf size=2: v0.10: 0.12434 v0.8: 0.10097 ..................... 23.15% fs/write-stream buf size=1024: v0.10: 59.926 v0.8: 49.822 .................... 20.28% fs/write-stream buf size=65535: v0.10: 180.41 v0.8: 179.26 .................... 0.64% fs/write-stream buf size=1048576: v0.10: 181.49 v0.8: 176.73 .................. 2.70% fs/write-stream asc size=2: v0.10: 0.11133 v0.8: 0.08123 ..................... 37.06% fs/write-stream asc size=1024: v0.10: 53.023 v0.8: 36.708 .................... 44.45% fs/write-stream asc size=65535: v0.10: 178.54 v0.8: 174.36 .................... 2.39% fs/write-stream asc size=1048576: v0.10: 185.27 v0.8: 183.65 .................. 0.88% fs/write-stream utf size=2: v0.10: 0.11165 v0.8: 0.080079 .................... 39.43% fs/write-stream utf size=1024: v0.10: 45.166 v0.8: 32.636 .................... 38.39% fs/write-stream utf size=65535: v0.10: 176.1 v0.8: 175.34 ..................... 0.43% fs/write-stream utf size=1048576: v0.10: 182.3 v0.8: 182.82 .................. -0.28%
We switched to a newer version of OpenSSL, and the CryptoStream implementation was significantly changed to support the Stream2 interface.
The throughput of TLS connections is massively improved:
tls/throughput.js dur=5 type=buf size=2: v0.10: 0.90836 v0.8: 0.32381 ....... 180.52% tls/throughput.js dur=5 type=buf size=1024: v0.10: 222.84 v0.8: 116.75 ....... 90.87% tls/throughput.js dur=5 type=buf size=1048576: v0.10: 403.17 v0.8: 360.42 .... 11.86% tls/throughput.js dur=5 type=asc size=2: v0.10: 0.78323 v0.8: 0.28761 ....... 172.32% tls/throughput.js dur=5 type=asc size=1024: v0.10: 199.7 v0.8: 102.46 ........ 94.91% tls/throughput.js dur=5 type=asc size=1048576: v0.10: 375.85 v0.8: 317.81 .... 18.26% tls/throughput.js dur=5 type=utf size=2: v0.10: 0.78503 v0.8: 0.28834 ....... 172.26% tls/throughput.js dur=5 type=utf size=1024: v0.10: 182.43 v0.8: 100.3 ........ 81.88% tls/throughput.js dur=5 type=utf size=1048576: v0.10: 333.05 v0.8: 301.57 .... 10.44%
However, the speed at which we can make connections is somewhat reduced:
tls/tls-connect.js concurrency=1 dur=5: v0.10: 433.05 v0.8: 560.43 .......... -22.73% tls/tls-connect.js concurrency=10 dur=5: v0.10: 438.38 v0.8: 577.93 ......... -24.15%
At this point, it seems like the connection speed is related to the new version of OpenSSL, but we'll be tracking that further.
TLS still has more room for improvement, but this throughput increase is a huge step.
The net throughput tests tell an interesting story. When sending ascii messages, they're much faster.
net/net-c2s.js len=102400 type=asc dur=5: v0.10: 3.6551 v0.8: 2.0478 ......... 78.49% net/net-c2s.js len=16777216 type=asc dur=5: v0.10: 3.2428 v0.8: 2.0503 ....... 58.16% net/net-pipe.js len=102400 type=asc dur=5: v0.10: 4.4638 v0.8: 3.0798 ........ 44.94% net/net-pipe.js len=16777216 type=asc dur=5: v0.10: 3.9449 v0.8: 2.8906 ...... 36.48% net/net-s2c.js len=102400 type=asc dur=5: v0.10: 3.6306 v0.8: 2.0415 ......... 77.84% net/net-s2c.js len=16777216 type=asc dur=5: v0.10: 3.2271 v0.8: 2.0636 ....... 56.38%
When sending Buffer messages, they're just slightly slower. (This difference is less than the typical variability of the test, but they were run 20 times and outliers were factored out for this post.)
net/net-c2s.js len=102400 type=buf dur=5: v0.10: 5.5597 v0.8: 5.6967 ......... -2.40% net/net-c2s.js len=16777216 type=buf dur=5: v0.10: 6.1843 v0.8: 6.4595 ....... -4.26% net/net-pipe.js len=102400 type=buf dur=5: v0.10: 5.6898 v0.8: 5.986 ......... -4.95% net/net-pipe.js len=16777216 type=buf dur=5: v0.10: 5.9643 v0.8: 5.9251 ....... 0.66% net/net-s2c.js len=102400 type=buf dur=5: v0.10: 5.473 v0.8: 5.6492 .......... -3.12% net/net-s2c.js len=16777216 type=buf dur=5: v0.10: 6.1986 v0.8: 6.3236 ....... -1.98%
When sending utf-8 messages, they're a bit slower than that:
net/net-c2s.js len=102400 type=utf dur=5: v0.10: 2.2671 v0.8: 2.4606 ......... -7.87% net/net-c2s.js len=16777216 type=utf dur=5: v0.10: 1.7434 v0.8: 1.8771 ....... -7.12% net/net-pipe.js len=102400 type=utf dur=5: v0.10: 3.1679 v0.8: 3.5401 ....... -10.51% net/net-pipe.js len=16777216 type=utf dur=5: v0.10: 2.5615 v0.8: 2.7002 ...... -5.14% net/net-s2c.js len=102400 type=utf dur=5: v0.10: 2.2495 v0.8: 2.4578 ......... -8.48% net/net-s2c.js len=16777216 type=utf dur=5: v0.10: 1.7733 v0.8: 1.8975 ....... -6.55%
You might suspect that this is a result of the new Streams
implementation. However, running the same benchmarks without using
any of the code in Node's
lib/ folder, just calling into the C++
bindings directly, yields consistently similar results.
This slight regression comes along with significant improvements in everything that sits on top of TCP (that is, TLS and HTTP).
Keep an eye out for more work in this area. Fast is never fast enough!
To support a higher degree of stability, and hopefully catch issues sooner, we have a Jenkins instance running every commit through the test suite, on each operating system we support. You can watch the action at the Node Jenkins web portal.
Coming soon, we'll have automatically generated nightly builds every day, and eventually, the entire release process will be automated.
While we're pretty rigorous about running tests and benchmarks, it's easy for things to slip by, and our ad-hoc methods are not cutting it any longer. This promises a much lower incidence of the sort of regressions that delayed the release of v0.10 for several months.
A year ago, we said that the innovation in the Node universe would be
happening in userland modules. Now, we've finally taken that to its
logical conclusion, and moved our iteration on core modules into
userland as well. Things like
us to get much more user-testing, experimentation, and contributions
to a feature.
The userland module can live on as a compatibility layer so that libraries can use the new features, even if they need to support older versions of Node. This is a remarkably effective way to do node-core development. Future developments will continue to be iterated in userland modules.
The question comes up pretty often whether Node is "ready for prime time" yet. I usually answer that it depends on your requirements for "prime time", but Node has been powering some high profile sites, and the options for "real" companies using Node for The Business are better than ever.
It would be out of scope to try to provide an exhaustive list of all the companies using Node, and all of the options for support and training. However, here are a few resources that are quickly expanding to fill the "Enterprise Node" space.
For those looking for commercial support, StrongLoop (Ben Noordhuis & Bert Belder's company) has released a distribution containing node v0.10 that they will support on Windows, Mac, Red Hat/Fedora, Debian/Ubuntu and multiple cloud platforms. You can download their Node distribution here.
The Node Firm is a worldwide network of key Node contributors and community members that help organizations succeed with Node. Through corporate training, consulting, architectural guidance, and ongoing consulting subscriptions, they have helped Skype, Qualcomm, and others quickly and effectively embrace Node.
Node would not be what it is without npm, and npm would not be what it is without the registry of published modules. However, relying on the public registry is problematic for many enterprise use-cases. Iris npm is a fully managed private npm registry, from Iris Couch, the team that runs the public npm registry in production.
Joyent, the company you probably know as the custodian of the Node project, provides high performance cloud infrastructure specializing in real-time web and mobile applications. Joyent uses Node extensively throughout their stack, and provides impressive post-mortem debugging and real-time performance analysis tools for Node.js applications. They are also my employer, so I'd probably have to get a "real" job if they weren't sponsoring Node :)
Next Up: v0.12
The focus of Node v0.12 will be to make HTTP better. Node's current HTTP implementation is pretty good, and clearly sufficient to do a lot of interesting things with. However:
- The codebase is a mess. We share a lot of code between the Client and Server implementations, but do so in a way that makes it unnecessarily painful to read the code or fix bugs. It will be split up so that client and server are clearly separated, and have cleaner interfaces.
- The socket pooling behavior is confusing and weird. We will be adding configurable socket pooling as a standalone utility. This will allow us to implement KeepAlive behavior in a more reasonable manner, as well as providing something that you can use in your own programs.
There is some experimentation going on in the tlsnappy module, which may make its way back into the core TLS implementation and speed things up considerably.
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.
New versions will still come out, especially to pull in new versions of our dependencies, and bugs will continue to be fixed. There's been talk of pinning our release cycles to V8, and automating the release process in some interesting ways.
The goal of Node has always been to eventually be "finished" with the core program. Of course, that's a rather lofty goal, perhaps even impossible. But as we take Node to more places, and use it in more ways, we're getting closer to the day when the relevant innovation happens outside of the core Node program.
Stability in the platform enables growth on top of it.
And now, the traditional release notes:
2013.03.11, Version 0.10.0 (Stable)
npm: Upgrade to 1.2.14
core: Append filename properly in dlopen on windows (isaacs)
zlib: Manage flush flags appropriately (isaacs)
domains: Handle errors thrown in nested error handlers (isaacs)
buffer: Strip high bits when converting to ascii (Ben Noordhuis)
win/msi: Enable modify and repair (Bert Belder)
win/msi: Add feature selection for various Node parts (Bert Belder)
win/msi: use consistent registry key paths (Bert Belder)
child_process: support sending dgram socket (Andreas Madsen)
fs: Raise EISDIR on Windows when calling fs.read/write on a dir (isaacs)
unix: fix strict aliasing warnings, macro-ify functions (Ben Noordhuis)
unix: honor UV_THREADPOOL_SIZE environment var (Ben Noordhuis)
win/tty: fix typo in color attributes enumeration (Bert Belder)
win/tty: don't touch insert mode or quick edit mode (Bert Belder)
Source Code: http://nodejs.org/dist/v0.10.0/node-v0.10.0.tar.gz
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.0/node-v0.10.0.pkg
Windows Installer: http://nodejs.org/dist/v0.10.0/node-v0.10.0-x86.msi
Windows x64 Installer: http://nodejs.org/dist/v0.10.0/x64/node-v0.10.0-x64.msi
Windows x64 Files: http://nodejs.org/dist/v0.10.0/x64/
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.0/node-v0.10.0-linux-x86.tar.gz
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.0/node-v0.10.0-linux-x64.tar.gz
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.0/node-v0.10.0-sunos-x86.tar.gz
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.0/node-v0.10.0-sunos-x64.tar.gz
Other release files: http://nodejs.org/dist/v0.10.0/
b9e9bca99cdb5563cad3d3f04baa262e317b827c node-v0.10.0-darwin-x64.tar.gz 0227c9bc3df5b62267b9d4e3b0a92b3a70732229 node-v0.10.0-darwin-x86.tar.gz 9f5f7350d6f889ea8e794516ecfea651e8e53d24 node-v0.10.0-linux-x64.tar.gz cc5f1cd6a2f2530bc400e761144bbaf8fcb66cc4 node-v0.10.0-linux-x86.tar.gz 42c14b7eab398976b1ac0a8e6e96989059616af5 node-v0.10.0-sunos-x64.tar.gz ddcadbac66d1acea48aa6c5462d0a0d7308ea823 node-v0.10.0-sunos-x86.tar.gz 70eacf2cca7abec79fac4ca502e8d99590a2108a node-v0.10.0-x86.msi c48c269b9b0f0a95e6e9234d4597d1c8a1c45c5a node-v0.10.0.pkg 7321266347dc1c47ed2186e7d61752795ce8a0ef node-v0.10.0.tar.gz f8c6f55469551243ea461f023cc57c024f57fef2 node.exe 253ae79e411fcfddcf28861559ececb4b335db64 node.exp acb8febb5ea714c065f201ced5423b0838fdf1b6 node.lib 0fdad1400036dd26d720070f783d3beeb3bb9c0a node.pdb abcaf8ef606655a05e73ee5d06715ffd022aad22 x64/node-v0.10.0-x64.msi e5d0c235629b26430b6e07c07ee2c7dcda82f35e x64/node.exe 43b3fb3a6aaf6a04f578ee607a9455c1e23acf08 x64/node.exp 87dd6eb6c8127a1af0dcca639961441fc303d75a x64/node.lib 50aca715777fa42b854e6cfc56b6199a54aabd3c x64/node.pdb