blog: Post about v0.10.0

1 files changed, 487 insertions, 0 deletions

diff --git a/doc/blog/release/v0.10.0.md b/doc/blog/release/v0.10.0.md
new file mode 100644
index 0000000000..b7bac4120e
--- /dev/null
+++ b/doc/blog/release/v0.10.0.md
@@ -0,0 +1,487 @@
+title: Node v0.10.0 (Stable)
+category: release
+version: 0.10.0
+date: 2013-03-11T16:00:00.000Z
+slug: node-v0-10-0-stable
+author: Isaac Z. Schlueter
+
+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](https://github.com/joyent/node/wiki/Api-changes-between-v0.8-and-v0.10).
+
+## Streams2
+
+In a [previous post](http://blog.nodejs.org/2012/12/20/streams2/), we
+introduced the
+"[Streams2](http://blog.nodejs.org/2012/12/20/streams2/)" API changes.
+If you haven't reviewed the changes, please go read that now (at least
+the tl;dr section).
+
+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](https://npmjs.org/browse/depended/readable-stream) already
+are using the
+[readable-stream](https://npmjs.org/package/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
+
+The `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 `process.on('uncaughtException')`
+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.
+
+## Faster process.nextTick
+
+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
+guaranteed.
+
+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
+after each call from C++ into JavaScript.  That means that, if your
+JavaScript code calls `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
+to `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](http://nodejs.org/benchmarks-v0.10-vs-v0.8/), as well.
+
+## Benchmarks: http
+
+Node is for websites, and websites run over HTTP, so this is the one
+that people usually care the most about:
+
+<pre style="background-color:#333;color:#eee;font-size:12px">
+http/cluster.js type=bytes length=4: <span style="background-color:#0f0;color:#000">v0.10: 16843</span> v0.8: 16202 ................. <span style="background-color:#0f0;color:#000">3.96%</span>
+http/cluster.js type=bytes length=1024: <span style="background-color:#0f0;color:#000">v0.10: 15505</span> v0.8: 15065 .............. <span style="background-color:#0f0;color:#000">2.92%</span>
+http/cluster.js type=bytes length=102400: v0.10: 1555.2 <span style="background-color:#f00;color:#fff">v0.8: 1566.3</span> ......... <span style="background-color:#f00;color:#fff">-0.71%</span>
+http/cluster.js type=buffer length=4: <span style="background-color:#0f0;color:#000">v0.10: 15308</span> v0.8: 14763 ................ <span style="background-color:#0f0;color:#000">3.69%</span>
+http/cluster.js type=buffer length=1024: <span style="background-color:#0f0;color:#000">v0.10: 15039</span> v0.8: 14830 ............. <span style="background-color:#0f0;color:#000">1.41%</span>
+http/cluster.js type=buffer length=102400: <span style="background-color:#0f0;color:#000">v0.10: 7584.6</span> v0.8: 7433.6 ......... <span style="background-color:#0f0;color:#000">2.03%</span>
+http/simple.js type=bytes length=4: <span style="background-color:#0f0;color:#000">v0.10: 12343</span> v0.8: 11761 .................. <span style="background-color:#0f0;color:#000">4.95%</span>
+http/simple.js type=bytes length=1024: <span style="background-color:#0f0;color:#000">v0.10: 11051</span> v0.8: 10287 ............... <span style="background-color:#0f0;color:#000">7.43%</span>
+http/simple.js type=bytes length=102400: v0.10: 853.19 <span style="background-color:#f00;color:#fff">v0.8: 892.75</span> .......... <span style="background-color:#f00;color:#fff">-4.43%</span>
+http/simple.js type=buffer length=4: <span style="background-color:#0f0;color:#000">v0.10: 11316</span> v0.8: 10728 ................. <span style="background-color:#0f0;color:#000">5.48%</span>
+http/simple.js type=buffer length=1024: <span style="background-color:#0f0;color:#000">v0.10: 11199</span> v0.8: 10429 .............. <span style="background-color:#0f0;color:#000">7.38%</span>
+http/simple.js type=buffer length=102400: <span style="background-color:#0f0;color:#000">v0.10: 4942.1</span> v0.8: 4822.9 .......... <span style="background-color:#0f0;color:#000">2.47%</span>
+</pre>
+
+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.
+
+## Benchmarks: fs
+
+The fs.ReadStream throughput is massively improved, and less affected
+by the chunk size argument:
+
+<pre style="background-color:#333;color:#eee;font-size:12px">
+fs/read-stream buf size=1024: <span style="background-color:#0f0;color:#000">v0.10</span>: 1106.6 v0.8: 60.597 ................... <span style="background-color:#0f0;color:#000">1726.12%</span>
+fs/read-stream buf size=4096: <span style="background-color:#0f0;color:#000">v0.10</span>: 1107.9 v0.8: 235.51 .................... <span style="background-color:#0f0;color:#000">370.44%</span>
+fs/read-stream buf size=65535: <span style="background-color:#0f0;color:#000">v0.10</span>: 1108.2 v0.8: 966.84 .................... <span style="background-color:#0f0;color:#000">14.62%</span>
+fs/read-stream buf size=1048576: <span style="background-color:#0f0;color:#000">v0.10</span>: 1103.3 v0.8: 959.66 .................. <span style="background-color:#0f0;color:#000">14.97%</span>
+fs/read-stream asc size=1024: <span style="background-color:#0f0;color:#000">v0.10</span>: 1081.5 v0.8: 62.218 ................... <span style="background-color:#0f0;color:#000">1638.21%</span>
+fs/read-stream asc size=4096: <span style="background-color:#0f0;color:#000">v0.10</span>: 1082.3 v0.8: 174.78 .................... <span style="background-color:#0f0;color:#000">519.21%</span>
+fs/read-stream asc size=65535: <span style="background-color:#0f0;color:#000">v0.10</span>: 1083.9 v0.8: 627.91 .................... <span style="background-color:#0f0;color:#000">72.62%</span>
+fs/read-stream asc size=1048576: <span style="background-color:#0f0;color:#000">v0.10</span>: 1083.2 v0.8: 627.49 .................. <span style="background-color:#0f0;color:#000">72.62%</span>
+fs/read-stream utf size=1024: <span style="background-color:#0f0;color:#000">v0.10</span>: 46.553 v0.8: 16.944 .................... <span style="background-color:#0f0;color:#000">174.74%</span>
+fs/read-stream utf size=4096: <span style="background-color:#0f0;color:#000">v0.10</span>: 46.585 v0.8: 32.933 ..................... <span style="background-color:#0f0;color:#000">41.45%</span>
+fs/read-stream utf size=65535: <span style="background-color:#0f0;color:#000">v0.10</span>: 46.57 v0.8: 45.832 ...................... <span style="background-color:#0f0;color:#000">1.61%</span>
+fs/read-stream utf size=1048576: <span style="background-color:#0f0;color:#000">v0.10</span>: 46.576 v0.8: 45.884 ................... <span style="background-color:#0f0;color:#000">1.51%</span>
+</pre>
+
+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.
+
+<pre style="background-color:#333;color:#eee;font-size:12px">
+fs/write-stream buf size=2: <span style="background-color:#0f0;color:#000">v0.10</span>: 0.12434 v0.8: 0.10097 ..................... <span style="background-color:#0f0;color:#000">23.15%</span>
+fs/write-stream buf size=1024: <span style="background-color:#0f0;color:#000">v0.10</span>: 59.926 v0.8: 49.822 .................... <span style="background-color:#0f0;color:#000">20.28%</span>
+fs/write-stream buf size=65535: <span style="background-color:#0f0;color:#000">v0.10</span>: 180.41 v0.8: 179.26 .................... <span style="background-color:#0f0;color:#000">0.64%</span>
+fs/write-stream buf size=1048576: <span style="background-color:#0f0;color:#000">v0.10</span>: 181.49 v0.8: 176.73 .................. <span style="background-color:#0f0;color:#000">2.70%</span>
+fs/write-stream asc size=2: <span style="background-color:#0f0;color:#000">v0.10</span>: 0.11133 v0.8: 0.08123 ..................... <span style="background-color:#0f0;color:#000">37.06%</span>
+fs/write-stream asc size=1024: <span style="background-color:#0f0;color:#000">v0.10</span>: 53.023 v0.8: 36.708 .................... <span style="background-color:#0f0;color:#000">44.45%</span>
+fs/write-stream asc size=65535: <span style="background-color:#0f0;color:#000">v0.10</span>: 178.54 v0.8: 174.36 .................... <span style="background-color:#0f0;color:#000">2.39%</span>
+fs/write-stream asc size=1048576: <span style="background-color:#0f0;color:#000">v0.10</span>: 185.27 v0.8: 183.65 .................. <span style="background-color:#0f0;color:#000">0.88%</span>
+fs/write-stream utf size=2: <span style="background-color:#0f0;color:#000">v0.10</span>: 0.11165 v0.8: 0.080079 .................... <span style="background-color:#0f0;color:#000">39.43%</span>
+fs/write-stream utf size=1024: <span style="background-color:#0f0;color:#000">v0.10</span>: 45.166 v0.8: 32.636 .................... <span style="background-color:#0f0;color:#000">38.39%</span>
+fs/write-stream utf size=65535: <span style="background-color:#0f0;color:#000">v0.10</span>: 176.1 v0.8: 175.34 ..................... <span style="background-color:#0f0;color:#000">0.43%</span>
+fs/write-stream utf size=1048576: v0.10: 182.3 <span style="background-color:#f00;color:#fff">v0.8</span>: 182.82 .................. <span style="background-color:#f00;color:#fff">-0.28%</span>
+</pre>
+
+## Benchmark: tls
+
+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:
+
+<pre style="background-color:#333;color:#eee;font-size:12px">
+tls/throughput.js dur=5 type=buf size=2: <span style="background-color:#0f0;color:#000">v0.10: 0.90836</span> v0.8: 0.32381 ....... <span style="background-color:#0f0;color:#000">180.52%</span>
+tls/throughput.js dur=5 type=buf size=1024: <span style="background-color:#0f0;color:#000">v0.10: 222.84</span> v0.8: 116.75 ....... <span style="background-color:#0f0;color:#000">90.87%</span>
+tls/throughput.js dur=5 type=buf size=1048576: <span style="background-color:#0f0;color:#000">v0.10: 403.17</span> v0.8: 360.42 .... <span style="background-color:#0f0;color:#000">11.86%</span>
+tls/throughput.js dur=5 type=asc size=2: <span style="background-color:#0f0;color:#000">v0.10: 0.78323</span> v0.8: 0.28761 ....... <span style="background-color:#0f0;color:#000">172.32%</span>
+tls/throughput.js dur=5 type=asc size=1024: <span style="background-color:#0f0;color:#000">v0.10: 199.7</span> v0.8: 102.46 ........ <span style="background-color:#0f0;color:#000">94.91%</span>
+tls/throughput.js dur=5 type=asc size=1048576: <span style="background-color:#0f0;color:#000">v0.10: 375.85</span> v0.8: 317.81 .... <span style="background-color:#0f0;color:#000">18.26%</span>
+tls/throughput.js dur=5 type=utf size=2: <span style="background-color:#0f0;color:#000">v0.10: 0.78503</span> v0.8: 0.28834 ....... <span style="background-color:#0f0;color:#000">172.26%</span>
+tls/throughput.js dur=5 type=utf size=1024: <span style="background-color:#0f0;color:#000">v0.10: 182.43</span> v0.8: 100.3 ........ <span style="background-color:#0f0;color:#000">81.88%</span>
+tls/throughput.js dur=5 type=utf size=1048576: <span style="background-color:#0f0;color:#000">v0.10: 333.05</span> v0.8: 301.57 .... <span style="background-color:#0f0;color:#000">10.44%</span>
+</pre>
+
+However, the speed at which we can make connections is somewhat
+reduced:
+
+<pre style="background-color:#333;color:#eee;font-size:12px">
+tls/tls-connect.js concurrency=1 dur=5: v0.10: 433.05 <span style="background-color:#f00;color:#fff">v0.8: 560.43</span> .......... <span style="background-color:#f00;color:#fff">-22.73%</span>
+tls/tls-connect.js concurrency=10 dur=5: v0.10: 438.38 <span style="background-color:#f00;color:#fff">v0.8: 577.93</span> ......... <span style="background-color:#f00;color:#fff">-24.15%</span>
+</pre>
+
+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.
+
+## Benchmark: net
+
+The net throughput tests tell an interesting story.  When sending
+ascii messages, they're much faster.
+
+<pre style="background-color:#333;color:#eee;font-size:12px">
+net/net-c2s.js len=102400 type=asc dur=5: <span style="background-color:#0f0;color:#000">v0.10: 3.6551</span> v0.8: 2.0478 ......... <span style="background-color:#0f0;color:#000">78.49%</span>
+net/net-c2s.js len=16777216 type=asc dur=5: <span style="background-color:#0f0;color:#000">v0.10: 3.2428</span> v0.8: 2.0503 ....... <span style="background-color:#0f0;color:#000">58.16%</span>
+net/net-pipe.js len=102400 type=asc dur=5: <span style="background-color:#0f0;color:#000">v0.10: 4.4638</span> v0.8: 3.0798 ........ <span style="background-color:#0f0;color:#000">44.94%</span>
+net/net-pipe.js len=16777216 type=asc dur=5: <span style="background-color:#0f0;color:#000">v0.10: 3.9449</span> v0.8: 2.8906 ...... <span style="background-color:#0f0;color:#000">36.48%</span>
+net/net-s2c.js len=102400 type=asc dur=5: <span style="background-color:#0f0;color:#000">v0.10: 3.6306</span> v0.8: 2.0415 ......... <span style="background-color:#0f0;color:#000">77.84%</span>
+net/net-s2c.js len=16777216 type=asc dur=5: <span style="background-color:#0f0;color:#000">v0.10: 3.2271</span> v0.8: 2.0636 ....... <span style="background-color:#0f0;color:#000">56.38%</span>
+</pre>
+
+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.)
+
+<pre style="background-color:#333;color:#eee;font-size:12px">
+net/net-c2s.js len=102400 type=buf dur=5: v0.10: 5.5597 <span style="background-color:#f00;color:#fff">v0.8: 5.6967</span> ......... <span style="background-color:#f00;color:#fff">-2.40%</span>
+net/net-c2s.js len=16777216 type=buf dur=5: v0.10: 6.1843 <span style="background-color:#f00;color:#fff">v0.8: 6.4595</span> ....... <span style="background-color:#f00;color:#fff">-4.26%</span>
+net/net-pipe.js len=102400 type=buf dur=5: v0.10: 5.6898 <span style="background-color:#f00;color:#fff">v0.8: 5.986</span> ......... <span style="background-color:#f00;color:#fff">-4.95%</span>
+net/net-pipe.js len=16777216 type=buf dur=5: <span style="background-color:#0f0;color:#000">v0.10: 5.9643</span> v0.8: 5.9251 ....... <span style="background-color:#0f0;color:#000">0.66%</span>
+net/net-s2c.js len=102400 type=buf dur=5: v0.10: 5.473 <span style="background-color:#f00;color:#fff">v0.8: 5.6492</span> .......... <span style="background-color:#f00;color:#fff">-3.12%</span>
+net/net-s2c.js len=16777216 type=buf dur=5: v0.10: 6.1986 <span style="background-color:#f00;color:#fff">v0.8: 6.3236</span> ....... <span style="background-color:#f00;color:#fff">-1.98%</span>
+</pre>
+
+When sending utf-8 messages, they're a bit slower than that:
+
+<pre style="background-color:#333;color:#eee;font-size:12px">
+net/net-c2s.js len=102400 type=utf dur=5: v0.10: 2.2671 <span style="background-color:#f00;color:#fff">v0.8: 2.4606</span> ......... <span style="background-color:#f00;color:#fff">-7.87%</span>
+net/net-c2s.js len=16777216 type=utf dur=5: v0.10: 1.7434 <span style="background-color:#f00;color:#fff">v0.8: 1.8771</span> ....... <span style="background-color:#f00;color:#fff">-7.12%</span>
+net/net-pipe.js len=102400 type=utf dur=5: v0.10: 3.1679 <span style="background-color:#f00;color:#fff">v0.8: 3.5401</span> ....... <span style="background-color:#f00;color:#fff">-10.51%</span>
+net/net-pipe.js len=16777216 type=utf dur=5: v0.10: 2.5615 <span style="background-color:#f00;color:#fff">v0.8: 2.7002</span> ...... <span style="background-color:#f00;color:#fff">-5.14%</span>
+net/net-s2c.js len=102400 type=utf dur=5: v0.10: 2.2495 <span style="background-color:#f00;color:#fff">v0.8: 2.4578</span> ......... <span style="background-color:#f00;color:#fff">-8.48%</span>
+net/net-s2c.js len=16777216 type=utf dur=5: v0.10: 1.7733 <span style="background-color:#f00;color:#fff">v0.8: 1.8975</span> ....... <span style="background-color:#f00;color:#fff">-6.55%</span>
+</pre>
+
+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!
+
+
+## Continuous Integration
+
+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](http://jenkins.nodejs.org/).
+
+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.
+
+
+## Growing Out
+
+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 `readable-stream` and `tlsnappy` allow
+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.
+
+## Growing Up <a name="enterprise"></a>
+
+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](http://strongloop.com/) (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](http://strongloop.com/products#downloads).
+
+[The Node Firm](http://thenodefirm.com) 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](http://thenodefirm.com/nodejs-consulting-subscriptions),
+they have helped Skype, Qualcomm, and others quickly and effectively
+embrace Node.
+
+Node would not be what it is without [npm](https://npmjs.org/), 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](https://www.irisnpm.com/) is a fully
+managed private npm registry, from [Iris
+Couch](http://www.iriscouch.com), the team that runs the public npm
+registry in production.
+
+[Joyent](http://joyent.com), 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](http://dtrace.org/blogs/dap/2012/05/31/debugging-node-js-in-production-fluent-slides/)
+for Node.js applications.  They are my also 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:
+
+1. 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.
+2. 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](https://github.com/indutny/tlsnappy) module, which may make
+its way back into the core TLS implementation and speed things up
+considerably.
+
+## 1.0
+
+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/
+
+Website: http://nodejs.org/docs/v0.10.0/
+
+Documentation: http://nodejs.org/docs/v0.10.0/api/
+
+Shasums:
+
+```
+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
+```