mirror of https://github.com/lukechilds/node.git
Browse Source
The website will no longer be living in the source repository instead it can be found at http://github.com/joyent/node-websitev0.10.26-release
Timothy J Fontaine
11 years ago
333 changed files with 4 additions and 24345 deletions
@ -1,147 +0,0 @@ |
|||
<!doctype html> |
|||
<html lang="en"> |
|||
<head> |
|||
<meta charset="utf-8"> |
|||
<link type="image/x-icon" rel="icon" href="../favicon.ico"> |
|||
<link type="image/x-icon" rel="shortcut icon" href="../favicon.ico"> |
|||
<link rel="stylesheet" href="../pipe.css"> |
|||
<link rel="stylesheet" href="../sh.css"> |
|||
<link rel="alternate" |
|||
type="application/rss+xml" |
|||
title="node blog" |
|||
href="http://feeds.feedburner.com/nodejs/123123123"> |
|||
<title>node.js</title> |
|||
</head> |
|||
<body class="alt int" id="about"> |
|||
<div id="intro" class="interior"> |
|||
<a href="/" title="Go back to the home page"> |
|||
<img id="logo" src="http://nodejs.org/images/logo-light.png" alt="node.js"> |
|||
</a> |
|||
</div> |
|||
<div id="content" class="clearfix"> |
|||
<div id="column2" class="interior"> |
|||
<ul> |
|||
<li><a href="/" class="home">Home</a></li> |
|||
<li><a href="/download/" class="download">Download</a></li> |
|||
<li><a href="/about/" class="about current">About</a></li> |
|||
<li><a href="http://npmjs.org/" class="npm">npm Registry</a></li> |
|||
<li><a href="http://nodejs.org/api/" class="docs">Docs</a></li> |
|||
<li><a href="http://blog.nodejs.org" class="blog">Blog</a></li> |
|||
<li><a href="/community/" class="community">Community</a></li> |
|||
<li><a href="/logos/" class="logos">Logos</a></li> |
|||
<li><a href="http://jobs.nodejs.org/" class="jobs">Jobs</a></li> |
|||
</ul> |
|||
<p class="twitter"><a href="http://twitter.com/nodejs">@nodejs</a></p> |
|||
</div> |
|||
|
|||
<div id="column1" class="interior"> |
|||
<h1>Node's goal is to provide an easy way to build scalable |
|||
network programs</h1> |
|||
|
|||
|
|||
<p>In the "hello world" web server example |
|||
below, many client connections can be handled concurrently. |
|||
Node tells the operating system (through <code>epoll</code>, |
|||
<code>kqueue</code>, <code>/dev/poll</code>, or |
|||
<code>select</code>) that it should be notified when a new |
|||
connection is made, and then it goes to sleep. If someone new |
|||
connects, then it executes the callback. Each connection is |
|||
only a small heap allocation.</p> |
|||
|
|||
<pre> |
|||
var http = require('http'); |
|||
http.createServer(function (req, res) { |
|||
res.writeHead(200, {'Content-Type': 'text/plain'}); |
|||
res.end('Hello World\n'); |
|||
}).listen(1337, "127.0.0.1"); |
|||
console.log('Server running at http://127.0.0.1:1337/');</pre> |
|||
<p>This is in contrast to today's more common concurrency |
|||
model where OS threads are employed. Thread-based networking |
|||
is relatively inefficient and very difficult to use. See: <a |
|||
href="http://www.kegel.com/c10k.html">this</a> and <a |
|||
href="http://bulk.fefe.de/scalable-networking.pdf">this</a>. |
|||
Node will show much better memory efficiency under high-loads |
|||
than systems which allocate 2mb thread stacks for each |
|||
connection. Furthermore, users of Node are free from worries |
|||
of dead-locking the process—there are no locks. Almost no |
|||
function in Node directly performs I/O, so the process never |
|||
blocks. Because nothing blocks, less-than-expert programmers |
|||
are able to develop fast systems.</p> |
|||
|
|||
<p>Node is similar in design to and influenced by systems like |
|||
Ruby's <a href="http://rubyeventmachine.com/">Event |
|||
Machine</a> or Python's <a |
|||
href="http://twistedmatrix.com/">Twisted</a>. Node takes the |
|||
event model a bit further—it presents the event loop as a |
|||
language construct instead of as a library. In other systems |
|||
there is always a blocking call to start the event-loop. |
|||
Typically one defines behavior through callbacks at the |
|||
beginning of a script and at the end starts a server through a |
|||
blocking call like <code>EventMachine::run()</code>. In Node |
|||
there is no such start-the-event-loop call. Node simply enters |
|||
the event loop after executing the input script. Node exits |
|||
the event loop when there are no more callbacks to perform. |
|||
This behavior is like browser javascript—the event loop is |
|||
hidden from the user.</p> |
|||
|
|||
<p>HTTP is a first class protocol in Node. Node's HTTP library |
|||
has grown out of the author's experiences developing and |
|||
working with web servers. For example, streaming data through |
|||
most web frameworks is impossible. Node attempts to correct |
|||
these problems in its HTTP <a |
|||
href="https://github.com/joyent/http-parser/tree/master">parser</a> |
|||
and API. Coupled with Node's purely evented infrastructure, it |
|||
makes a good foundation for web libraries or frameworks.</p> |
|||
|
|||
<p>But what about multiple-processor concurrency? Aren't |
|||
threads necessary to scale programs to multi-core computers? |
|||
You can start new processes via <code><a |
|||
href="http://nodejs.org/api/child_process.html#child_process.fork">child_process.fork()</a></code> |
|||
these other processes will be scheduled in parallel. For load |
|||
balancing incoming connections across multiple processes use |
|||
<a href="http://nodejs.org/api/cluster.html">the |
|||
cluster module</a>.</p> |
|||
|
|||
<p>See also:</p> |
|||
<ul> |
|||
<li><a href="http://s3.amazonaws.com/four.livejournal/20091117/jsconf.pdf">Slides from JSConf 2009</a></li> |
|||
<li><a href="http://nodejs.org/jsconf2010.pdf">Slides from JSConf 2010</a></li> |
|||
<li><a href="http://www.yuiblog.com/blog/2010/05/20/video-dahl/">Video from a talk at Yahoo in May 2010</a></li> |
|||
</ul> |
|||
</div> |
|||
</div> |
|||
<div id="footer"> |
|||
<a href="http://joyent.com" class="joyent-logo">Joyent</a> |
|||
<ul class="clearfix"> |
|||
<li><a href="/">Node.js</a></li> |
|||
<li><a href="/#download">Download</a></li> |
|||
<li><a href="/about/">About</a></li> |
|||
<li><a href="http://npmjs.org/">npm Registry</a></li> |
|||
<li><a href="http://nodejs.org/api/">Docs</a></li> |
|||
<li><a href="http://blog.nodejs.org">Blog</a></li> |
|||
<li><a href="/community/">Community</a></li> |
|||
<li><a href="/logos/">Logos</a></li> |
|||
<li><a href="http://jobs.nodejs.org/">Jobs</a></li> |
|||
<li><a href="http://twitter.com/nodejs" class="twitter">@nodejs</a></li> |
|||
</ul> |
|||
|
|||
<p>Copyright <a href="http://joyent.com/">Joyent, Inc</a>, Node.js is a <a href="/trademark-policy.pdf">trademark</a> of Joyent, Inc. View <a href="https://raw.github.com/joyent/node/__VERSION__/LICENSE">license</a>.</p> |
|||
</div> |
|||
|
|||
|
|||
<script src="../sh_main.js"></script> |
|||
<script src="../sh_javascript.min.js"></script> |
|||
<script>highlight(undefined, undefined, 'pre');</script> |
|||
|
|||
<script> |
|||
window._gaq = [['_setAccount', 'UA-10874194-2'], ['_trackPageview']]; |
|||
(function(d, t) { |
|||
var g = d.createElement(t), |
|||
s = d.getElementsByTagName(t)[0]; |
|||
g.src = '//www.google-analytics.com/ga.js'; |
|||
s.parentNode.insertBefore(g, s); |
|||
}(document, 'script')); |
|||
</script> |
|||
|
|||
</body> |
|||
</html> |
|||
@ -1,241 +0,0 @@ |
|||
<!DOCTYPE html> |
|||
|
|||
<html lang="en"> |
|||
<head> |
|||
<meta charset="utf-8"> |
|||
<link rel="stylesheet" href="http://nodejs.org/pipe.css"> |
|||
<link rel="stylesheet" href="http://nodejs.org/sh_vim-dark.css"> |
|||
<style> |
|||
#column1 h1 { |
|||
clear:both; |
|||
} |
|||
#column1 { |
|||
font-size: 14px; |
|||
} |
|||
#column1 li, #content h1 + p { |
|||
color:inherit; |
|||
font-family: inherit; |
|||
font-size: 14px; |
|||
line-height:24px; |
|||
} |
|||
#column1 li p + ul { |
|||
margin-top:-1em; |
|||
} |
|||
#column1 ul li ul { |
|||
font-size:12px; |
|||
line-height:24px; |
|||
padding-left: 0; |
|||
} |
|||
#column1 ul li ul li { |
|||
list-style:none; |
|||
margin-left:0; |
|||
} |
|||
#column1 ul li ul li:before { |
|||
content: "- "; |
|||
} |
|||
#content #column1 p.meta, #content #column1 p.respond { |
|||
font-size: 14px; |
|||
line-height: 24px; |
|||
color:#690; |
|||
font-family: inherit; |
|||
} |
|||
#content #column1 p.respond { |
|||
font-style:italic; |
|||
padding:2em 0; |
|||
} |
|||
#column1 a { |
|||
color: #8c0; |
|||
} |
|||
#column2 ul { |
|||
padding:0; |
|||
} |
|||
#column2 { |
|||
margin-top:-66px!important; |
|||
} |
|||
div.post-in-feed { |
|||
padding-bottom:1em; |
|||
} |
|||
|
|||
p.next { float:right; width: 40%; text-align:right; } |
|||
p.prev { float:left; width:40%; text-align:left; } |
|||
|
|||
pre { overflow: auto; } |
|||
</style> |
|||
|
|||
<title><%= title || "Node.js Blog" %></title> |
|||
<link rel="alternate" type="application/rss+xml" |
|||
title="Node.js Blog RSS" |
|||
href="http://blog.nodejs.org/feed<%= |
|||
(typeof posts !== 'undefined') ? uri : '/' |
|||
%>"> |
|||
</head> |
|||
|
|||
<body class="int blog" id="<%= pageid %>"> |
|||
<div id="intro" class="interior"> |
|||
<a href="/" title="Go back to the home page"><img id="logo" src= |
|||
"http://nodejs.org/logo.png" alt="node.js"></a> |
|||
</div> |
|||
|
|||
<div id="content" class="clearfix"> |
|||
<div id="column2" class="interior"> |
|||
<ul> |
|||
<li><a href="http://nodejs.org/" class="home">Home</a></li> |
|||
|
|||
<li><a href="http://nodejs.org/download/" class= |
|||
"download">Download</a></li> |
|||
|
|||
<li><a href="http://nodejs.org/about/" class="about">About</a></li> |
|||
|
|||
<li><a href="http://npmjs.org/" class="npm">npm |
|||
Registry</a></li> |
|||
|
|||
<li><a href="http://nodejs.org/api/" class="docs">Docs</a></li> |
|||
|
|||
<li><a href="http://blog.nodejs.org/" class="blog current">Blog</a></li> |
|||
|
|||
<li><a href="http://nodejs.org/community/" class= |
|||
"community">Community</a></li> |
|||
|
|||
<li><a href="http://nodejs.org/logos/" class= |
|||
"logos">Logos</a></li> |
|||
|
|||
<li><a href="http://jobs.nodejs.org/" class="jobs">Jobs</a></li> |
|||
</ul> |
|||
|
|||
<p class="twitter"><a href="http://twitter.com/nodejs">@nodejs</a></p> |
|||
</div> |
|||
|
|||
<div id="column1" class="interior"> |
|||
<h1><%- title %></h1> |
|||
<% if (typeof post !== 'undefined') { |
|||
// just one post on this page |
|||
%> |
|||
<p class="meta"><%- |
|||
post.date.toUTCString().replace(/ GMT$/, '') + ' UTC' + |
|||
(post.author ? ' - ' + post.author : '') + |
|||
(post.category ? ' - <a href="/' + post.category + '/">' + |
|||
post.category + '</a>' : '') |
|||
%></p> |
|||
|
|||
<%- post.content %> |
|||
|
|||
<p class="respond">Please post feedback and comments on |
|||
<a href="https://groups.google.com/group/nodejs">the Node.JS |
|||
user mailing list</a>.<br> |
|||
Please post bugs and feature requests on |
|||
<a href="https://github.com/joyent/node/issues">the Node.JS |
|||
github repository</a>.</p> |
|||
|
|||
<% |
|||
if (post.next || post.prev) { |
|||
if (post.prev) { |
|||
%><p class="prev"><a href="<%= |
|||
post.prev.permalink |
|||
%>">← <%= |
|||
post.prev.title |
|||
%></a></p> |
|||
<% |
|||
} |
|||
if (post.next) { |
|||
%><p class="next"><a href="<%= |
|||
post.next.permalink |
|||
%>"><%= |
|||
post.next.title |
|||
%> →</a></p> |
|||
<% |
|||
} |
|||
} |
|||
} else { // not single post page |
|||
if (paginated && total > 1 ) { |
|||
if (page > 0) { |
|||
// add 1 to all of the displayed numbers, because |
|||
// humans are not zero-indexed like they ought to be. |
|||
%> |
|||
<p class="prev"><a href="<%= uri + (page - 1) %>"> |
|||
← Page <%- page %> |
|||
</a></p> |
|||
<% |
|||
} |
|||
if (page < total - 1) { %> |
|||
<p class="next"><a href="<%= uri + (page + 1) %>"> |
|||
Page <%- page + 2 %> → |
|||
</a></p> |
|||
<% |
|||
} |
|||
} |
|||
|
|||
posts.forEach(function(post) { |
|||
%> |
|||
<div class="post-in-feed"> |
|||
<h1><a href="<%= |
|||
post.permalink |
|||
%>" class="permalink"><%- |
|||
post.title |
|||
%></a></h1> |
|||
|
|||
<p class="meta"><%- |
|||
post.date.toUTCString().replace(/ GMT$/, '') + ' UTC' + |
|||
(post.author ? ' - ' + post.author : '') + |
|||
(post.category ? ' - <a href="/' + post.category + '/">' + |
|||
post.category + '</a>' : '') |
|||
%></p> |
|||
|
|||
<%- post.content %> |
|||
</div> |
|||
<% |
|||
}); |
|||
|
|||
if (paginated && total > 1 ) { |
|||
if (page > 0) { |
|||
// add 1 to all of the displayed numbers, because |
|||
// humans are not zero-indexed like they ought to be. |
|||
%> |
|||
<p class="prev"><a href="<%= uri + (page - 1) %>"> |
|||
← Page <%- page %> |
|||
</a></p> |
|||
<% |
|||
} |
|||
if (page < total - 1) { %> |
|||
<p class="next"><a href="<%= uri + (page + 1) %>"> |
|||
Page <%- page + 2 %> → |
|||
</a></p> |
|||
<% |
|||
} |
|||
} // pagination |
|||
} // not a single post |
|||
%> |
|||
</div> |
|||
</div> |
|||
|
|||
<div id="footer"> |
|||
<a href="http://joyent.com" class="joyent-logo">Joyent</a> |
|||
<ul class="clearfix"> |
|||
<li><a href="http://nodejs.org/">Node.js</a></li> |
|||
<li><a href="http://nodejs.org/download/">Download</a></li> |
|||
<li><a href="http://nodejs.org/about/">About</a></li> |
|||
<li><a href="http://npmjs.org/">npm Registry</a></li> |
|||
<li><a href="http://nodejs.org/api/">Docs</a></li> |
|||
<li><a href="http://blog.nodejs.org">Blog</a></li> |
|||
<li><a href="http://nodejs.org/community/">Community</a></li> |
|||
<li><a href="https://nodejs.org/logos/">Logos</a></li> |
|||
<li><a href="http://jobs.nodejs.org/">Jobs</a></li> |
|||
<li><a href="http://twitter.com/nodejs" class="twitter">@nodejs</a></li> |
|||
</ul> |
|||
|
|||
<p>Copyright <a href="http://joyent.com/">Joyent, Inc</a>, Node.js is a <a href="/trademark-policy.pdf">trademark</a> of Joyent, Inc. View <a href="https://raw.github.com/joyent/node/master/LICENSE">license</a>.</p> |
|||
</div> |
|||
|
|||
<script src="../sh_main.js"></script> |
|||
<script src="../sh_javascript.min.js"></script> |
|||
<script>highlight(undefined, undefined, 'pre');</script> |
|||
<script> |
|||
window._gaq = [['_setAccount', 'UA-10874194-2'], ['_trackPageview']]; |
|||
(function(d, t) { |
|||
var g = d.createElement(t), |
|||
s = d.getElementsByTagName(t)[0]; |
|||
g.src = '//www.google-analytics.com/ga.js'; |
|||
s.parentNode.insertBefore(g, s); |
|||
}(document, 'script')); |
|||
</script> |
|||
</body> |
|||
</html> |
|||
@ -1,28 +0,0 @@ |
|||
title: README.md |
|||
status: private |
|||
|
|||
# How This Blog Works |
|||
|
|||
Each `.md` file in this folder structure is a blog post. It has a |
|||
few headers and a markdown body. (HTML is allowed in the body as well.) |
|||
|
|||
The relevant headers are: |
|||
|
|||
1. title |
|||
2. author |
|||
3. status: Only posts with a status of "publish" are published. |
|||
4. category: The "release" category is treated a bit specially. |
|||
5. version: Only relevant for "release" category. |
|||
6. date |
|||
7. slug: The bit that goes on the url. Must be unique, will be |
|||
generated from the title and date if missing. |
|||
|
|||
Posts in the "release" category are only shown in the main lists when |
|||
they are the most recent release for that version family. The stable |
|||
branch supersedes its unstable counterpart, so the presence of a `0.8.2` |
|||
release notice will cause `0.7.10` to be hidden, but `0.6.19` would |
|||
be unaffected. |
|||
|
|||
The folder structure in the blog source does not matter. Organize files |
|||
here however makes sense. The metadata will be sorted out in the build |
|||
later. |
|||
@ -1,16 +0,0 @@ |
|||
title: An Easy Way to Build Scalable Network Programs |
|||
author: ryandahl |
|||
date: Tue Oct 04 2011 15:39:56 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: an-easy-way-to-build-scalable-network-programs |
|||
|
|||
Suppose you're writing a web server which does video encoding on each file upload. Video encoding is very much compute bound. Some recent blog posts suggest that Node.js would fail miserably at this. |
|||
|
|||
Using Node does not mean that you have to write a video encoding algorithm in JavaScript (a language without even 64 bit integers) and crunch away in the main server event loop. The suggested approach is to separate the I/O bound task of receiving uploads and serving downloads from the compute bound task of video encoding. In the case of video encoding this is accomplished by forking out to ffmpeg. Node provides advanced means of asynchronously controlling subprocesses for work like this. |
|||
|
|||
It has also been suggested that Node does not take advantage of multicore machines. Node has long supported load-balancing connections over multiple processes in just a few lines of code - in this way a Node server will use the available cores. In coming releases we'll make it even easier: just pass <code>--balance</code> on the command line and Node will manage the cluster of processes. |
|||
|
|||
Node has a clear purpose: provide an easy way to build scalable network programs. It is not a tool for every problem. Do not write a ray tracer with Node. Do not write a web browser with Node. Do however reach for Node if tasked with writing a DNS server, DHCP server, or even a video encoding server. |
|||
|
|||
By relying on the kernel to schedule and preempt computationally expensive tasks and to load balance incoming connections, Node appears less magical than server platforms that employ userland scheduling. So far, our focus on simplicity and transparency has paid off: <a href="http://www.joyent.com/blog/node-js-meetup-distributed-web-architectures/">the</a> <a href="http://venturebeat.com/2011/08/16/linkedin-node/">number</a> <a href="http://corp.klout.com/blog/2011/10/the-tech-behind-klout-com/">of</a> <a href="http://www.joelonsoftware.com/items/2011/09/13.html">success</a> <a href="http://pow.cx/">stories</a> from developers and corporations who are adopting the technology continues to grow. |
|||
@ -1,17 +0,0 @@ |
|||
title: Ben Noordhuis's Departure |
|||
date: Tue Dec 3 14:13:57 PST 2013 |
|||
slug: bnoordhuis-departure |
|||
|
|||
As of this past weekend, Ben Noordhuis has decided to step away from |
|||
Node.js and libuv, and is no longer acting as a core committer. |
|||
|
|||
Ben has done a tremendous amount of great work in the past. We're sad |
|||
to lose the benefit of his continued hard work and expertise, and |
|||
extremely grateful for what he has added to Node.js and libuv over the |
|||
years. |
|||
|
|||
Many of you already have expressed your opinion regarding recent |
|||
drama, and I'd like to ask that you please respect our wishes to let |
|||
this issue rest, so that we can all focus on the road forward. |
|||
|
|||
Thanks. |
|||
@ -1,25 +0,0 @@ |
|||
title: Development Environment |
|||
author: ryandahl |
|||
date: Mon Apr 04 2011 20:16:27 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: development-environment |
|||
|
|||
If you're compiling a software package because you need a particular version (e.g. the latest), then it requires a little bit more maintenance than using a package manager like <code>dpkg</code>. Software that you compile yourself should *not* go into <code>/usr</code>, it should go into your home directory. This is part of being a software developer. |
|||
|
|||
One way of doing this is to install everything into <code>$HOME/local/$PACKAGE</code>. Here is how I install node on my machine:<pre>./configure --prefix=$HOME/local/node-v0.4.5 && make install</pre> |
|||
|
|||
To have my paths automatically set I put this inside my <code>$HOME/.zshrc</code>:<pre>PATH="$HOME/local/bin:/opt/local/bin:/usr/bin:/sbin:/bin" |
|||
LD_LIBRARY_PATH="/opt/local/lib:/usr/local/lib:/usr/lib" |
|||
for i in $HOME/local/*; do |
|||
[ -d $i/bin ] && PATH="${i}/bin:${PATH}" |
|||
[ -d $i/sbin ] && PATH="${i}/sbin:${PATH}" |
|||
[ -d $i/include ] && CPATH="${i}/include:${CPATH}" |
|||
[ -d $i/lib ] && LD_LIBRARY_PATH="${i}/lib:${LD_LIBRARY_PATH}" |
|||
[ -d $i/lib/pkgconfig ] && PKG_CONFIG_PATH="${i}/lib/pkgconfig:${PKG_CONFIG_PATH}" |
|||
[ -d $i/share/man ] && MANPATH="${i}/share/man:${MANPATH}" |
|||
done</pre> |
|||
|
|||
Node is under sufficiently rapid development that <i>everyone</i> should be compiling it themselves. A corollary of this is that <code>npm</code> (which should be installed alongside Node) does not require root to install packages. |
|||
|
|||
CPAN and RubyGems have blurred the lines between development tools and system package managers. With <code>npm</code> we wish to draw a clear line: it is not a system package manager. It is not for installing firefox or ffmpeg or OpenSSL; it is for rapidly downloading, building, and setting up Node packages. <code>npm</code> is a <i>development</i> tool. When a program written in Node becomes sufficiently mature it should be distributed as a tarball, <code>.deb</code>, <code>.rpm</code>, or other package system. It should not be distributed to end users with <code>npm</code>. |
|||
@ -1,34 +0,0 @@ |
|||
title: Evolving the Node.js Brand |
|||
author: Emily Tanaka-Delgado |
|||
date: Mon Jul 11 2011 12:02:45 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: evolving-the-node-js-brand |
|||
|
|||
To echo <a href="http://nodejs.org/">Node</a>’s evolutionary nature, we have refreshed the identity to help mark an exciting time for developers, businesses and users who benefit from the pioneering technology. |
|||
|
|||
<strong>Building a brand</strong> |
|||
|
|||
We began exploring elements to express Node.js and jettisoned preconceived notions about what we thought Node should look like, and focused on what Node is: <strong>kinetic</strong>,<ins cite="mailto:EMILY%20TANAKA-DELGADO" datetime="2011-07-09T18:32"></ins><strong>connected</strong>, <strong>scalable</strong>, <strong>modular</strong>, <strong>mechanical</strong> and <strong>organic</strong>. Working with designer <a href="http://www.chrisglass.com">Chris Glass</a>, our explorations emphasized Node's dynamism and formed a visual language based on structure, relationships and interconnectedness. |
|||
|
|||
<img class="alignnone size-full wp-image-184" title="grid" src="http://nodeblog.files.wordpress.com/2011/07/grid.png" alt="" width="520" height="178" /> |
|||
|
|||
Inspired by <strong>process visualization, </strong>we discovered pattern, form, and by relief, the hex shape. The angled infrastructure encourages energy to move through the letterforms. |
|||
|
|||
<img class="alignnone size-full wp-image-185" title="nodejs" src="http://nodeblog.files.wordpress.com/2011/07/nodejs.png" alt="" width="520" height="178" /> |
|||
|
|||
This language can expand into the organic network topography of Node or distill down into a single hex connection point. |
|||
|
|||
This scaling represents the dynamic nature of Node in a simple, distinct manner. |
|||
|
|||
<img title="Node.js network" src="http://joyeur.files.wordpress.com/2011/07/network.png" alt="" width="560" height="270" /> |
|||
|
|||
We look forward to exploring<ins cite="mailto:EMILY%20TANAKA-DELGADO" datetime="2011-07-09T18:30"> </ins>this visual language as the technology charges into a very promising future. |
|||
|
|||
<img title="Node.js nebula" src="http://joyeur.files.wordpress.com/2011/07/node.png" alt="" width="560" height="460" /> |
|||
|
|||
We hope you'll have fun using it. |
|||
|
|||
To download the new logo, visit <a href="http://nodejs.org/logos/">nodejs.org/logos</a>. |
|||
|
|||
<ins cite="mailto:EMILY%20TANAKA-DELGADO" datetime="2011-07-09T18:32"><img title="Tri-color Node" src="http://joyeur.files.wordpress.com/2011/07/tri-color-node.png" alt="" width="560" height="180" /></ins> |
|||
@ -1,12 +0,0 @@ |
|||
title: Growing up |
|||
author: ryandahl |
|||
date: Thu Dec 15 2011 11:59:15 GMT-0800 (PST) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: growing-up |
|||
|
|||
This week Microsoft announced <a href="https://www.windowsazure.com/en-us/develop/nodejs/">support for Node in Windows Azure</a>, their cloud computing platform. For the Node core team and the community, this is an important milestone. We've worked hard over the past six months reworking Node's machinery to support IO completion ports and Visual Studio to provide a good native port to Windows. The overarching goal of the port was to expand our user base to the largest number of developers. Happily, this has paid off in the form of being a first class citizen on Azure. Many users who would have never used Node as a pure unix tool are now up and running on the Windows platform. More users translates into a deeper and better ecosystem of modules, which makes for a better experience for everyone. |
|||
|
|||
We also redesigned <a href="http://nodejs.org">our website</a> - something that we've put off for a long time because we felt that Node was too nascent to dedicate marketing to it. But now that we have binary distributions for Macintosh and Windows, have bundled npm, and are <a href="https://twitter.com/#!/mranney/status/145778414165569536">serving millions of users</a> at various companies, we felt ready to indulge in a new website and share of a few of our success stories on the home page. |
|||
|
|||
Work is on-going. We continue to improve the software, making performance improvements and adding isolate support, but Node is growing up. |
|||
@ -1,14 +0,0 @@ |
|||
title: jobs.nodejs.org |
|||
author: ryandahl |
|||
date: Thu Mar 24 2011 23:05:22 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: jobs-nodejs-org |
|||
|
|||
We are starting an official jobs board for Node. There are two goals for this |
|||
|
|||
1. Promote the small emerging economy around this platform by having a central space for employers to find Node programmers. |
|||
|
|||
2. Make some money. We work hard to build this platform and taking a small tax for job posts seems a like reasonable "tip jar". |
|||
|
|||
<a href="http://jobs.nodejs.org">jobs.nodejs.org</a> |
|||
@ -1,84 +0,0 @@ |
|||
title: ldapjs: A reprise of LDAP |
|||
author: mcavage |
|||
date: Thu Sep 08 2011 14:25:43 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: ldapjs-a-reprise-of-ldap |
|||
|
|||
This post has been about 10 years in the making. My first job out of college was at IBM working on the <a title="Tivoli Directory Server" href="http://www-01.ibm.com/software/tivoli/products/directory-server/">Tivoli Directory Server</a>, and at the time I had a preconceived notion that working on anything related to Internet RFCs was about as hot as you could get. I spent a lot of time back then getting "down and dirty" with everything about LDAP: the protocol, performance, storage engines, indexing and querying, caching, customer use cases and patterns, general network server patterns, etc. Basically, I soaked up as much as I possibly could while I was there. On top of that, I listened to all the "gray beards" tell me about the history of LDAP, which was a bizarre marriage of telecommunications conglomerates and graduate students. The point of this blog post is to give you a crash course in LDAP, and explain what makes <a title="ldapjs" href="http://ldapjs.org">ldapjs</a> different. Allow me to be the gray beard for a bit... |
|||
<h2>What is LDAP and where did it come from?</h2> |
|||
|
|||
Directory services were largely pioneered by the telecommunications companies (e.g., AT&T) to allow fast information retrieval of all the crap you'd expect would be in a telephone book and directory. That is, given a name, or an address, or an area code, or a number, or a foo support looking up customer records, billing information, routing information, etc. The efforts of several telcos came to exist in the <a title="X.500" href="http://en.wikipedia.org/wiki/X.500">X.500</a> standard(s). An X.500 directory is one of the most complicated beasts you can possibly imagine, but on a high note, there's |
|||
probably not a thing you can imagine in a directory service that wasn't thought of in there. It is literally the kitchen sink. Oh, and it doesn't run over IP (it's <em>actually</em> on the <a title="OSI Model" href="http://en.wikipedia.org/wiki/OSI_model">OSI</a> model). |
|||
|
|||
Several years after X.500 had been deployed (at telcos, academic institutions, etc.), it became clear that the Internet was "for real." <a title="LDAP" href="http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol">LDAP</a>, the "Lightweight Directory Access Protocol," was invented to act purely as an IP-accessible gateway to an X.500 directory. |
|||
|
|||
At some point in the early 90's, a <a title="Tim Howes" href="http://en.wikipedia.org/wiki/Tim_Howes">graduate student</a> at the University of Michigan (with some help) cooked up the "grandfather" implementation of the LDAP protocol, which wasn't actually a "gateway," but rather a stand-alone implementation of LDAP. Said implementation, like many things at the time, was a process-per-connection concurrency model, and had "backends" (aka storage engine) for the file system and the Unix DB API. At some point the <a title="Berkeley Database" href="http://www.oracle.com/technetwork/database/berkeleydb/index.html">Berkeley Database </a>(BDB) was put in, and still remains the de facto storage engine for most LDAP directories. |
|||
|
|||
Ok, so some a graduate student at UM wrote an LDAP server that wasn't a gateway. So what? Well, that UM code base turns out to be the thing that pretty much every vendor did a source license for. Those graduate students went off to Netscape later in the 90's, and largely dominated the market of LDAP middleware until <a title="Active Directory" href="http://en.wikipedia.org/wiki/Active_Directory">Active Directory</a> came along many years later (as far as I know, Active Directory is "from scratch", since while it's "almost" LDAP, it's different in a lot of ways). That Netscape code base was further bought and sold over the years to iPlanet, Sun Microsystems, and Red Hat (I'm probably missing somebody in that chain). It now lives in the Fedora umbrella as '<a title="389 Directory Server" href="http://directory.fedoraproject.org/">389 Directory Server</a>.' Probably the most popular fork of that code base now is <a title="OpenLDAP" href="http://www.openldap.org/">OpenLDAP</a>. |
|||
|
|||
IBM did the same thing, and the Directory Server I worked on was a fork of the UM code too, but it heavily diverged from the Netscape branches. The divergence was primarily due to: (1) backing to DB2 as opposed to BDB, and (2) needing to run on IBM's big iron like OS/400 and Z series mainframes. |
|||
|
|||
Macro point is that there have actually been very few "fresh" implementations of LDAP, and it gets a pretty bad reputation because at the end of the day you've got 20 years of "bolt-ons" to grad student code. Oh, and it was born out of ginormous telcos, so of course the protocol is overly complex. |
|||
|
|||
That said, while there certainly is some wacky stuff in the LDAP protocol itself, it really suffered from poor and buggy implementations more than the fact that LDAP itself was fundamentally flawed. As <a title="Engine Yard LDAP" href="http://www.engineyard.com/blog/2009/ldap-directories-the-forgotten-nosql/">engine yard pointed out a few years back</a>, you can think of LDAP as the original NoSQL store. |
|||
<h2>LDAP: The Good Parts</h2> |
|||
|
|||
So what's awesome about LDAP? Since it's a directory system it maintains a hierarchy of your data, which as an information management pattern aligns |
|||
with _a lot_ of use case (the quintessential example is white pages for people in your company, but subscriptions to SaaS applications, "host groups" |
|||
for tracking machines/instances, physical goods tracking, etc., all have use cases that fit that organization scheme). For example, presumably at your job |
|||
you have a "reporting chain." Let's say a given record in LDAP (I'll use myself as a guinea pig here) looks like: |
|||
<pre> firstName: Mark |
|||
lastName: Cavage |
|||
city: Seattle |
|||
uid: markc |
|||
state: Washington |
|||
mail: mcavagegmailcom |
|||
phone: (206) 555-1212 |
|||
title: Software Engineer |
|||
department: 123456 |
|||
objectclass: joyentPerson</pre> |
|||
The record for me would live under the tree of engineers I report to (and as an example some other popular engineers under said vice president) would look like: |
|||
<pre> uid=david |
|||
/ |
|||
uid=bryan |
|||
/ | \ |
|||
uid=markc uid=ryah uid=isaacs</pre> |
|||
Ok, so we've got a tree. It's not tremendously different from your filesystem, but how do we find people? LDAP has a rich search filter syntax that makes a lot of sense for key/value data (far more than tacking Map Reduce jobs on does, imo), and all search queries take a "start point" in the tree. Here's an example: let's say I wanted to find all "Software Engineers" in the entire company, a filter would look like: |
|||
<pre> (title="Software Engineer")</pre> |
|||
And I'd just start my search from 'uid=david' in the example above. Let's say I wanted to find all software engineers who worked in Seattle: |
|||
<pre> (&(title="Software Engineer")(city=Seattle))</pre> |
|||
I could keep going, but the gist is that LDAP has "full" boolean predicate logic, wildcard filters, etc. It's really rich. |
|||
|
|||
Oh, and on top of the technical merits, better or worse, it's an established standard for both administrators and applications (i.e., most "shipped" intranet software has either a local user repository or the ability to leverage an LDAP server somewhere). So there's a lot of compelling reasons to look at leveraging LDAP. |
|||
<h2>ldapjs: Why do I care?</h2> |
|||
|
|||
As I said earlier, I spent a lot of time at IBM observing how customers used LDAP, and the real items I took away from that experience were: |
|||
<ul> |
|||
<li>LDAP implementations have suffered a lot from never having been designed from the ground up for a large number of concurrent connections with asynchronous operations.</li> |
|||
<li>There are use cases for LDAP that just don't always fit the traditional "here's my server and storage engine" model. A lot of simple customer use cases wanted an LDAP access point, but not be forced into taking the heavy backends that came with it (they wanted the original gateway model!). There was an entire "sub" industry for this known as "<a title="Metadirectory" href="http://en.wikipedia.org/wiki/Metadirectory">meta directories</a>" back in the late 90's and early 2000's.</li> |
|||
<li>Replication was always a sticking point. LDAP vendors all tried to offer a big multi-master, multi-site replication model. It was a lot of "bolt-on" complexity, done before the <a title="CAP Theorem" href="http://en.wikipedia.org/wiki/CAP_theorem">CAP theorem</a> was written, and certainly before it was accepted as "truth."</li> |
|||
<li>Nobody uses all of the protocol. In fact, 20% of the features solve 80% of the use cases (I'm making that number up, but you get the idea).</li> |
|||
</ul> |
|||
|
|||
For all the good parts of LDAP, those are really damned big failing points, and even I eventually abandoned LDAP for the greener pastures of NoSQL somewhere |
|||
along the way. But it always nagged at me that LDAP didn't get it's due because of a lot of implementation problems (to be clear, if I could, I'd change some |
|||
aspects of the protocol itself too, but that's a lot harder). |
|||
|
|||
Well, in the last year, I went to work for <a title="Joyent" href="http://www.joyent.com/">Joyent</a>, and like everyone else, we have several use problems that are classic directory service problems. If you break down the list I outlined above: |
|||
<ul> |
|||
<li><strong>Connection-oriented and asynchronous:</strong> Holy smokes batman, <a title="node.js" href="http://nodejs.org/">node.js</a> is a completely kick-ass event-driven asynchronous server platform that manages connections like a boss. Check!</li> |
|||
<li><strong>Lots of use cases:</strong> Yeah, we've got some. Man, the <a title="sinatra" href="http://www.sinatrarb.com/">sinatra</a>/<a title="express" href="http://expressjs.com/">express</a> paradigm is so easy to slap over anything. How about we just do that and leave as many use cases open as we can. Check!</li> |
|||
<li><strong>Replication is hard. CAP is right:</strong> There are a lot of distributed databases out vying to solve exactly this problem. At Joyent we went with <a title="Riak" href="http://www.basho.com/">Riak</a>. Check!</li> |
|||
<li><strong>Don't need all of the protocol:</strong> I'm lazy. Let's just skip the stupid things most people don't need. Check!</li> |
|||
</ul> |
|||
|
|||
So that's the crux of ldapjs right there. Giving you the ability to put LDAP back into your application while nailing those 4 fundamental problems that plague most existing LDAP deployments. |
|||
|
|||
The obvious question is how it turned out, and the answer is, honestly, better than I thought it would. When I set out to do this, I actually assumed I'd be shipping a much smaller percentage of the RFC than is there. There's actually about 95% of the core RFC implemented. I wasn't sure if the marriage of this protocol to node/JavaScript would work out, but if you've used express ever, this should be _really_ familiar. And I tried to make it as natural as possible to use "pure" JavaScript objects, rather than requiring the developer to understand <a title="ASN.1" href="http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One">ASN.1</a> (the binary wire protocol) or the<a title="RFC 4510" href="http://tools.ietf.org/html/rfc4510"> LDAP RFC</a> in detail (this one mostly worked out; ldap_modify is still kind of a PITA). |
|||
|
|||
Within 24 hours of releasing ldapjs on <a title="twitter" href="http://twitter.com/#!/mcavage/status/106767571012952064">Twitter</a>, there was an <a title="github ldapjs address book" href="https://gist.github.com/1173999">implementation of an address book</a> that works with Thunderbird/Evolution, by the end of that weekend there was some <a href="http://i.imgur.com/uR16U.png">slick integration with CouchDB</a>, and ldapjs even got used in one of the <a href="http://twitter.com/#!/jheusala/status/108977708649811970">node knockout apps</a>. Off to a pretty good start! |
|||
|
|||
<h2>The Road Ahead</h2> |
|||
|
|||
Hopefully you've been motivated to learn a little bit more about LDAP and try out <a href="http://ldapjs.org">ldapjs</a>. The best place to start is probably the <a title="ldapjs guide" href="http://ldapjs.org/guide.html">guide</a>. After that you'll probably need to pick up a book from <a href="http://www.amazon.com/Understanding-Deploying-LDAP-Directory-Services/dp/0672323168">back in the day</a>. ldapjs itself is still in its infancy; there's quite a bit of room to add some slick client-side logic (e.g., connection pools, automatic reconnects), easy to use schema validation, backends, etc. By the time this post is live, there will be experimental <a href="http://en.wikipedia.org/wiki/DTrace">dtrace</a> support if you're running on Mac OS X or preferably Joyent's <a href="http://smartos.org/">SmartOS</a> (shameless plug). And that nagging percentage of the protocol I didn't do will get filled in over time I suspect. If you've got an interest in any of this, send me some pull requests, but most importantly, I just want to see LDAP not just be a skeleton in the closet and get used in places where you should be using it. So get out there and write you some LDAP. |
|||
@ -1,45 +0,0 @@ |
|||
title: libuv status report |
|||
author: ryandahl |
|||
date: Fri Sep 23 2011 12:45:50 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: libuv-status-report |
|||
|
|||
We <a href="http://blog.nodejs.org/2011/06/23/porting-node-to-windows-with-microsoft%E2%80%99s-help/">announced</a> back in July that with Microsoft's support Joyent would be porting Node to Windows. This effort is ongoing but I thought it would be nice to make a status report post about the new platform library <code><a href="https://github.com/joyent/libuv">libuv</a></code> which has resulted from porting Node to Windows. |
|||
|
|||
<code>libuv</code>'s purpose is to abstract platform-dependent code in Node into one place where it can be tested for correctness and performance before bindings to V8 are added. Since Node is totally non-blocking, <code>libuv</code> turns out to be a rather useful library itself: a BSD-licensed, minimal, high-performance, cross-platform networking library. |
|||
|
|||
We attempt to not reinvent the wheel where possible. The entire Unix backend sits heavily on Marc Lehmann's beautiful libraries <a href="http://software.schmorp.de/pkg/libev.html">libev</a> and <a href="http://software.schmorp.de/pkg/libeio.html">libeio</a>. For DNS we integrated with Daniel Stenberg's <a href="http://c-ares.haxx.se/">C-Ares</a>. For cross-platform build-system support we're relying on Chrome's <a href="http://code.google.com/p/gyp/">GYP</a> meta-build system. |
|||
|
|||
The current implemented features are: |
|||
<ul> |
|||
<li>Non-blocking TCP sockets (using IOCP on Windows)</li> |
|||
<li>Non-blocking named pipes</li> |
|||
<li>UDP</li> |
|||
<li>Timers</li> |
|||
<li>Child process spawning</li> |
|||
<li>Asynchronous DNS via <a href="http://c-ares.haxx.se/">c-ares</a> or <code>uv_getaddrinfo</code>.</li> |
|||
<li>Asynchronous file system APIs <code>uv_fs_*</code></li> |
|||
<li>High resolution time <code>uv_hrtime</code></li> |
|||
<li>Current executable path look up <code>uv_exepath</code></li> |
|||
<li>Thread pool scheduling <code>uv_queue_work</code></li> |
|||
</ul> |
|||
The features we are working on still are |
|||
<ul> |
|||
<li>File system events (Currently supports inotify, <code>ReadDirectoryChangesW</code> and will support kqueue and event ports in the near future.) <code>uv_fs_event_t</code></li> |
|||
<li>VT100 TTY <code>uv_tty_t</code></li> |
|||
<li>Socket sharing between processes <code>uv_ipc_t (<a href="https://gist.github.com/1233593">planned API</a>)</code></li> |
|||
</ul> |
|||
For complete documentation see the header file: <a href="https://github.com/joyent/libuv/blob/03d0c57ea216abd611286ff1e58d4e344a459f76/include/uv.h">include/uv.h</a>. There are a number of tests in <a href="https://github.com/joyent/libuv/tree/3ca382be741ec6ce6a001f0db04d6375af8cd642/test">the test directory</a> which demonstrate the API. |
|||
|
|||
<code>libuv</code> supports Microsoft Windows operating systems since Windows XP SP2. It can be built with either Visual Studio or MinGW. Solaris 121 and later using GCC toolchain. Linux 2.6 or better using the GCC toolchain. Macinotsh Darwin using the GCC or XCode toolchain. It is known to work on the BSDs but we do not check the build regularly. |
|||
|
|||
In addition to Node v0.5, a number of projects have begun to use <code>libuv</code>: |
|||
<ul> |
|||
<li>Mozilla's <a href="https://github.com/graydon/rust">Rust</a></li> |
|||
<li>Tim Caswell's <a href="https://github.com/creationix/luanode">LuaNode</a></li> |
|||
<li>Ben Noordhuis and Bert Belder's <a href="https://github.com/bnoordhuis/phode">Phode</a> async PHP project</li> |
|||
<li>Kerry Snyder's <a href="https://github.com/kersny/libuv-csharp">libuv-csharp</a></li> |
|||
<li>Andrea Lattuada's <a href="https://gist.github.com/1195428">web server</a></li> |
|||
</ul> |
|||
We hope to see more people contributing and using <code>libuv</code> in the future! |
|||
@ -1,11 +0,0 @@ |
|||
title: Node Meetup this Thursday |
|||
author: ryandahl |
|||
date: Tue Aug 02 2011 21:37:02 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: node-meetup-this-thursday |
|||
|
|||
<a href="http://nodejs.org/meetup/" title="http://nodejs.org/meetup/ ">http://nodejs.org/meetup/</a> |
|||
<a href="http://nodemeetup.eventbrite.com/">http://nodemeetup.eventbrite.com/</a> |
|||
|
|||
Three companies will describe their distributed Node applications. Sign up soon, space is limited! |
|||
@ -1,12 +0,0 @@ |
|||
title: Node Office Hours Cut Short |
|||
author: ryandahl |
|||
date: Thu Apr 28 2011 09:04:35 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: node-office-hours-cut-short |
|||
|
|||
This week office hours are only from 4pm to 6pm. Isaac will be in the Joyent office in SF - everyone else is out of town. Sign up at http://nodeworkup.eventbrite.com/ if you would like to come. |
|||
|
|||
The week after, Thursday May 5th, we will all be at NodeConf in Portland. |
|||
|
|||
Normal office hours resume Thursday May 12th. |
|||
@ -1,12 +0,0 @@ |
|||
title: Office Hours |
|||
author: ryandahl |
|||
date: Wed Mar 23 2011 21:42:47 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: office-hours |
|||
|
|||
Starting next Thursday Isaac, Tom, and I will be holding weekly office hours at <a href="http://maps.google.com/maps?q=345+California+St,+San+Francisco,+CA+94104&layer=c&sll=37.793040,-122.400491&cbp=13,178.31,,0,-60.77&cbll=37.793131,-122.400484&hl=en&sspn=0.006295,0.006295&ie=UTF8&hq=&hnear=345+California+St,+San+Francisco,+California+94104&ll=37.793131,-122.400484&spn=0.001295,0.003428&z=19&panoid=h0dlz3VG-hMKlzOu0LxMIg">Joyent HQ</a> in San Francisco. Office hours are meant to be subdued working time - there are no talks and no alcohol. Bring your bugs or just come and hack with us. |
|||
|
|||
Our building requires that everyone attending be on a list so you must sign up at <a href="http://nodeworkup01.eventbrite.com/">Event Brite</a>. |
|||
|
|||
We start at 4p and end promptly at 8p. |
|||
@ -1,12 +0,0 @@ |
|||
title: Porting Node to Windows With Microsoft’s Help |
|||
author: ryandahl |
|||
date: Thu Jun 23 2011 15:22:58 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: porting-node-to-windows-with-microsoft%e2%80%99s-help |
|||
|
|||
I'm pleased to announce that Microsoft is partnering with Joyent in formally contributing resources towards porting Node to Windows. As you may have heard in <a href="http://nodejs.org/nodeconf.pdf" title="a talk">a talk</a> we gave earlier this year, we have started the undertaking of a native port to Windows - targeting the high-performance IOCP API. |
|||
|
|||
This requires a rather large modification of the core structure, and we're very happy to have official guidance and engineering resources from Microsoft. <a href="https://www.cloudkick.com/">Rackspace</a> is also contributing <a href="https://github.com/piscisaureus">Bert Belder</a>'s time to this undertaking. |
|||
|
|||
The result will be an official binary node.exe releases on nodejs.org, which will work on Windows Azure and other Windows versions as far back as Server 2003. |
|||
@ -1,60 +0,0 @@ |
|||
title: Profiling Node.js |
|||
author: Dave Pacheco |
|||
date: Wed Apr 25 2012 13:48:58 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: profiling-node-js |
|||
|
|||
It's incredibly easy to visualize where your Node program spends its time using DTrace and <a href="http://github.com/davepacheco/node-stackvis">node-stackvis</a> (a Node port of Brendan Gregg's <a href="http://github.com/brendangregg/FlameGraph/">FlameGraph</a> tool): |
|||
|
|||
<ol> |
|||
<li>Run your Node.js program as usual.</li> |
|||
<li>In another terminal, run: |
|||
<pre> |
|||
$ dtrace -n 'profile-97/execname == "node" && arg1/{ |
|||
@[jstack(150, 8000)] = count(); } tick-60s { exit(0); }' > stacks.out</pre> |
|||
This will sample about 100 times per second for 60 seconds and emit results to stacks.out. <strong>Note that this will sample all running programs called "node". If you want a specific process, replace <code>execname == "node"</code> with <code>pid == 12345</code> (the process id).</strong> |
|||
</li> |
|||
<li>Use the "stackvis" tool to transform this directly into a flame graph. First, install it: |
|||
<pre>$ npm install -g stackvis</pre> |
|||
then use <code>stackvis</code> to convert the DTrace output to a flamegraph: |
|||
<pre>$ stackvis dtrace flamegraph-svg < stacks.out > stacks.svg</pre> |
|||
</li> |
|||
<li>Open stacks.svg in your favorite browser.</li> |
|||
</ol> |
|||
|
|||
You'll be looking at something like this: |
|||
|
|||
<a href="http://www.cs.brown.edu/~dap/helloworld.svg"><img src="http://dtrace.org/blogs/dap/files/2012/04/helloworld-flamegraph-550x366.png" alt="" title="helloworld-flamegraph" width="550" height="366" class="aligncenter size-large wp-image-1047" /></a> |
|||
|
|||
This is a visualization of all of the profiled call stacks. This example is from the "hello world" HTTP server on the <a href="http://nodejs.org">Node.js</a> home page under load. Start at the bottom, where you have "main", which is present in most Node stacks because Node spends most on-CPU time in the main thread. Above each row, you have the functions called by the frame beneath it. As you move up, you'll see actual JavaScript function names. The boxes in each row are not in chronological order, but their width indicates how much time was spent there. When you hover over each box, you can see exactly what percentage of time is spent in each function. This lets you see at a glance where your program spends its time. |
|||
|
|||
That's the summary. There are a few prerequisites: |
|||
|
|||
<ul> |
|||
<li>You must gather data on a system that supports DTrace with the Node.js ustack helper. For now, this pretty much means <a href="http://illumos.org/">illumos</a>-based systems like <a href="http://smartos.org/">SmartOS</a>, including the Joyent Cloud. <strong>MacOS users:</strong> OS X supports DTrace, but not ustack helpers. The way to get this changed is to contact your Apple developer liaison (if you're lucky enough to have one) or <strong>file a bug report at bugreport.apple.com</strong>. I'd suggest referencing existing bugs 5273057 and 11206497. More bugs filed (even if closed as dups) show more interest and make it more likely Apple will choose to fix this.</li> |
|||
<li>You must be on 32-bit Node.js 0.6.7 or later, built <code>--with-dtrace</code>. The helper doesn't work with 64-bit Node yet. On illumos (including SmartOS), development releases (the 0.7.x train) include DTrace support by default.</li> |
|||
</ul> |
|||
|
|||
There are a few other notes: |
|||
|
|||
<ul> |
|||
<li>You can absolutely profile apps <strong>in production</strong>, not just development, since compiling with DTrace support has very minimal overhead. You can start and stop profiling without restarting your program.</li> |
|||
<li>You may want to run the stacks.out output through <code>c++filt</code> to demangle C++ symbols. Be sure to use the <code>c++filt</code> that came with the compiler you used to build Node. For example: |
|||
<pre>c++filt < stacks.out > demangled.out</pre> |
|||
then you can use demangled.out to create the flamegraph. |
|||
</li> |
|||
<li>If you want, you can filter stacks containing a particular function. The best way to do this is to first collapse the original DTrace output, then grep out what you want: |
|||
<pre> |
|||
$ stackvis dtrace collapsed < stacks.out | grep SomeFunction > collapsed.out |
|||
$ stackvis collapsed flamegraph-svg < collapsed.out > stacks.svg</pre> |
|||
</li> |
|||
<li>If you've used Brendan's FlameGraph tools, you'll notice the coloring is a little different in the above flamegraph. I ported his tools to Node first so I could incorporate it more easily into other Node programs, but I've also been playing with different coloring options. The current default uses hue to denote stack depth and saturation to indicate time spent. (These are also indicated by position and size.) Other ideas include coloring by module (so V8, JavaScript, libc, etc. show up as different colors.) |
|||
</li> |
|||
</ul> |
|||
|
|||
For more on the underlying pieces, see my <a href="http://dtrace.org/blogs/dap/2012/01/05/where-does-your-node-program-spend-its-time/">previous post on Node.js profiling</a> and <a href="http://dtrace.org/blogs/brendan/2011/12/16/flame-graphs/">Brendan's post on Flame Graphs</a>. |
|||
|
|||
<hr /> |
|||
|
|||
Dave Pacheco blogs at <a href="http://dtrace.org/blogs/dap">dtrace.org</a> |
|||
@ -1,13 +0,0 @@ |
|||
title: Some New Node Projects |
|||
author: ryandahl |
|||
date: Mon Aug 29 2011 08:30:41 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: some-new-node-projects |
|||
|
|||
<ul> |
|||
<li>Superfeedr released <a href="http://blog.superfeedr.com/node-xmpp-server/">a Node XMPP Server</a>. "<i>Since <a href="http://spaceboyz.net/~astro/">astro</a> had been doing an <strong>amazing work</strong> with his <a href="https://github.com/astro/node-xmpp">node-xmpp</a> library to build <em>Client</em>, <em>Components</em> and even <em>Server to server</em> modules, the logical next step was to try to build a <em>Client to Server</em> module so that we could have a full blown server. That’s what we worked on the past couple days, and <a href="https://github.com/superfeedr/node-xmpp">it’s now on Github</a>!</i></li> |
|||
|
|||
<li>Joyent's Mark Cavage released <a href="http://ldapjs.org/">LDAP.js</a>. "<i>ldapjs is a pure JavaScript, from-scratch framework for implementing <a href="http://tools.ietf.org/html/rfc4510">LDAP</a> clients and servers in <a href="http://nodejs.org">Node.js</a>. It is intended for developers used to interacting with HTTP services in node and <a href="http://expressjs.com">express</a>.</i></li> |
|||
|
|||
<li>Microsoft's Tomasz Janczuk released <a href="http://tomasz.janczuk.org/2011/08/hosting-nodejs-applications-in-iis-on.html">iisnode</a> "<i>The <a href="https://github.com/tjanczuk/iisnode">iisnode</a> project provides a native IIS 7.x module that allows hosting of node.js applications in IIS.</i><br /><br />Scott Hanselman posted <a href="http://www.hanselman.com/blog/InstallingAndRunningNodejsApplicationsWithinIISOnWindowsAreYouMad.aspx">a detailed walkthrough</a> of how to get started with iisnode |
|||
@ -1,10 +0,0 @@ |
|||
title: The Videos from the Meetup |
|||
author: ryandahl |
|||
date: Fri Aug 12 2011 00:14:34 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: the-videos-from-node-meetup |
|||
|
|||
Uber, Voxer, and Joyent described how they use Node in production |
|||
|
|||
<a href="http://www.joyent.com/blog/node-js-meetup-distributed-web-architectures/">http://www.joyent.com/blog/node-js-meetup-distributed-web-architectures/</a> |
|||
@ -1,54 +0,0 @@ |
|||
title: The Next Phase of Node.js |
|||
date: Wed Jan 15 09:00:00 PST 2014 |
|||
author: Isaac Z. Schlueter |
|||
slug: the-next-phase-of-node-js |
|||
|
|||
Node's growth has continued and accelerated immensely over the last |
|||
few years. More people are developing and sharing more code with Node |
|||
and npm than I would have ever imagined. Countless companies are |
|||
using Node, and npm along with it. |
|||
|
|||
Over the last year, [TJ Fontaine](https://twitter.com/tjfontaine) has become absolutely essential to the |
|||
Node.js project. He's been building releases, managing the test bots, |
|||
[fixing nasty |
|||
bugs](http://www.joyent.com/blog/walmart-node-js-memory-leak) and |
|||
making decisions for the project with constant focus on the needs of |
|||
our users. He was responsible for an update to MDB to [support |
|||
running ::findjsobjects on Linux core |
|||
dumps](http://www.slideshare.net/bcantrill/node-summit2013), and is |
|||
working on a shim layer that will provide a stable C interface for |
|||
Node binary addons. In partnership with Joyent and The Node Firm, |
|||
he's helped to create a path forward for scalable issue triaging. |
|||
He's become the primary point of contact keeping us all driving the |
|||
project forward together. |
|||
|
|||
Anyone who's been close to the core project knows that he's been |
|||
effectively leading the project for a while now, so we're making it |
|||
official. Effective immediately, TJ Fontaine is the Node.js project |
|||
lead. I will remain a Node core committer, and expect to continue to |
|||
contribute to the project in that role. My primary focus, however, |
|||
will be npm. |
|||
|
|||
At this point, npm needs work, and I am eager to deliver what the Node |
|||
community needs from its package manager. I am starting a company, |
|||
npm, Inc., to deliver new products and services related to npm. I'll |
|||
be sharing many more details soon about exactly how this is going to |
|||
work, and what we'll be offering. For now, suffice it to say that |
|||
everything currently free will remain free, and everything currently |
|||
flaky will get less flaky. Pursuing new revenue is how we can keep |
|||
providing the npm registry service in a long-term sustainable way, and |
|||
it has to be done very carefully so that we don't damage what we've |
|||
all built together. |
|||
|
|||
npm is what I'm most passionate about, and I am now in a position to |
|||
give it my full attention. I've done more than I could have hoped to |
|||
accomplish in running Node core, and it's well past time to hand the |
|||
control of the project off to its next gatekeeper. |
|||
|
|||
TJ is exactly the leader who can help us take Node.js to 1.0 and |
|||
beyond. He brings professionalism, rigor, and a continued focus on |
|||
inclusive community values and culture. In the coming days, TJ will |
|||
spell out his plans in greater detail. I look forward to the places |
|||
that Node will go with his guidance. |
|||
|
|||
Please join me in welcoming him to this new role :) |
|||
@ -1,17 +0,0 @@ |
|||
title: Trademark |
|||
author: ryandahl |
|||
date: Fri Apr 29 2011 01:54:18 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: trademark |
|||
|
|||
One of the things Joyent accepted when we took on the Node project was to provide resources to help the community grow. The Node project is amazing because of the expertise, dedication and hard work of the community. However in all communities there is the possibility of people acting inappropriately. We decided to introduce trademarks on the “Node.js” and the “Node logo” in order to ensure that people or organisations who are not investing in the Node community misrepresent, or create confusion about the role of themselves or their products with Node. |
|||
|
|||
We are big fans of the people who have contributed to Node and we have worked hard to make sure that existing members of the community will be unaffected by this change. For most people they don’t have to do anything they are free to use the Node.js marks in their free open source projects (see guidelines). For others we’ve already granted them licenses to use Node.js marks in their domain names and their businesses. We value all of these contributions to the Node community and hope that we can continue to protect their good names and hard work. |
|||
|
|||
Where does our trademark policy come from? We started by looking at popular open source foundations like the Apache Software Foundation and Linux. By strongly basing our policy on the one used by the Apache Software Foundation we feel that we’ve created a policy which is liberal enough to allow the open source community to easily make use of the mark in the context of free open source software, but secure enough to protect the community’s work from being misrepresented by other organisations. |
|||
|
|||
While we realize that any changes involving lawyers can be intimidating to the community we want to make this transition as smoothly as possible and welcome your questions and feedback on the policy and how we are implementing it. |
|||
|
|||
<a href="http://nodejs.org/trademark-policy.pdf">http://nodejs.org/trademark-policy.pdf</a> |
|||
trademark@joyent.com |
|||
@ -1,23 +0,0 @@ |
|||
title: Version 0.6 Coming Soon |
|||
author: ryandahl |
|||
date: Tue Oct 25 2011 15:26:23 GMT-0700 (PDT) |
|||
status: publish |
|||
category: Uncategorized |
|||
slug: version-0-6 |
|||
|
|||
Version 0.6.0 will be released next week. Please spend some time this |
|||
week upgrading your code to v0.5.10. Report any API differences at <a |
|||
href="https://github.com/joyent/node/wiki/API-changes-between-v0.4-and-v0.6">https://github.com/joyent/node/wiki/API-changes-between-v0.4-and-v0.6</a> |
|||
or report a bug to us at <a |
|||
href="http://github.com/joyent/node/issues">http://github.com/joyent/node/issues</a> |
|||
if you hit problems. |
|||
|
|||
The API changes between v0.4.12 and v0.5.10 are 99% cosmetic, minor, |
|||
and easy to fix. Most people are able to migrate their code in 10 |
|||
minutes. Don't fear. |
|||
|
|||
Once you've ported your code to v0.5.10 please help out by testing |
|||
third party modules. Make bug reports. Encourage authors to publish |
|||
new versions of their modules. Go through the list of modules at <a |
|||
href="http://npmjs.org/">http://npmjs.org/</a> and try out random |
|||
ones. This is especially encouraged of Windows users! |
|||
|
Before Width: | Height: | Size: 1.1 KiB |
@ -1,851 +0,0 @@ |
|||
title: A New Streaming API for Node v0.10 |
|||
author: Isaac Z. Schlueter |
|||
date: Fri Dec 21 00:45:13 UTC 2012 |
|||
slug: streams2 |
|||
category: feature |
|||
|
|||
**tl;dr** |
|||
|
|||
* Node streams are great, except for all the ways in which they're |
|||
terrible. |
|||
* A new Stream implementation is coming in 0.10, that has gotten the |
|||
nickname "streams2". |
|||
* Readable streams have a `read()` method that returns a buffer or |
|||
null. (More documentation included below.) |
|||
* `'data'` events, `pause()`, and `resume()` will still work as before |
|||
(except that they'll actully work how you'd expect). |
|||
* Old programs will **almost always** work without modification, but |
|||
streams start out in a paused state, and need to be read from to be |
|||
consumed. |
|||
* **WARNING**: If you never add a `'data'` event handler, or call |
|||
`resume()`, then it'll sit in a paused state forever and never |
|||
emit `'end'`. |
|||
|
|||
------- |
|||
|
|||
Throughout the life of Node, we've been gradually iterating on the |
|||
ideal event-based API for handling data. Over time, this developed |
|||
into the "Stream" interface that you see throughout Node's core |
|||
modules and many of the modules in npm. |
|||
|
|||
Consistent interfaces increase the portability and reliability of our |
|||
programs and libraries. Overall, the move from domain-specific events |
|||
and methods towards a unified stream interface was a huge win. |
|||
However, there are still several problems with Node's streams as of |
|||
v0.8. In a nutshell: |
|||
|
|||
1. The `pause()` method doesn't pause. It is advisory-only. In |
|||
Node's implementation, this makes things much simpler, but it's |
|||
confusing to users, and doesn't do what it looks like it does. |
|||
2. `'data'` events come right away (whether you're ready or not). |
|||
This makes it unreasonably difficult to do common tasks like load a |
|||
user's session before deciding how to handle their request. |
|||
3. There is no way to consume a specific number of bytes, and then |
|||
leave the rest for some other part of the program to deal with. |
|||
4. It's unreasonably difficult to implement streams and get all the |
|||
intricacies of pause, resume, write-buffering, and data events |
|||
correct. The lack of shared classes mean that we all have to solve |
|||
the same problems repeatedly, making similar mistakes and similar |
|||
bugs. |
|||
|
|||
Common simple tasks should be easy, or we aren't doing our job. |
|||
People often say that Node is better than most other platforms at this |
|||
stuff, but in my opinion, that is less of a compliment and more of an |
|||
indictment of the current state of software. Being better than the |
|||
next guy isn't enough; we have to be the best imaginable. While they |
|||
were a big step in the right direction, the Streams in Node up until |
|||
now leave a lot wanting. |
|||
|
|||
So, just fix it, right? |
|||
|
|||
Well, we are sitting on the results of several years of explosive |
|||
growth in the Node community, so any changes have to be made very |
|||
carefully. If we break all the Node programs in 0.10, then no one |
|||
will ever want to upgrade to 0.10, and it's all pointless. We had |
|||
this conversation around 0.4, then again around 0.6, then again around |
|||
0.8. Every time, the conclusion has been "Too much work, too hard to |
|||
make backwards-compatible", and we always had more pressing problems |
|||
to solve. |
|||
|
|||
In 0.10, we cannot put it off any longer. We've bitten the bullet and |
|||
are making a significant change to the Stream implementation. You may |
|||
have seen conversations on twitter or IRC or the mailing list about |
|||
"streams2". I also gave [a talk in |
|||
November](https://dl.dropbox.com/u/3685/presentations/streams2/streams2-ko.pdf) |
|||
about this subject. A lot of node module authors have been involved |
|||
with the development of streams2 (and of course the node core team). |
|||
|
|||
## streams2 |
|||
|
|||
The feature is described pretty thoroughly in the documentation, so |
|||
I'm including it below. Please read it, especially the section on |
|||
"compatibility". There's a caveat there that is unfortunately |
|||
unavoidable, but hopefully enough of an edge case that it's easily |
|||
worked around. |
|||
|
|||
The first preview release with this change will be 0.9.4. I highly |
|||
recommend trying this release and providing feedback before it lands |
|||
in a stable version. |
|||
|
|||
As of writing this post, there are some known performance regressions, |
|||
especially in the http module. We are fanatical about maintaining |
|||
performance in Node.js, so of course this will have to be fixed before |
|||
the v0.10 stable release. (Watch for a future blog post on the tools |
|||
and techniques that have been useful in tracking down these issues.) |
|||
|
|||
There may be minor changes as necessary to fix bugs and improve |
|||
performance, but the API at this point should be considered feature |
|||
complete. It correctly does all the things we need it to do, it just |
|||
doesn't do them quite well enough yet. As always, be wary of running |
|||
unstable releases in production, of course, but I encourage you to try |
|||
it out and see what you think. Especially, if you have tests that you |
|||
can run on your modules and libraries, that would be extremely useful |
|||
feedback. |
|||
|
|||
-------- |
|||
|
|||
# Stream |
|||
|
|||
Stability: 2 - Unstable |
|||
|
|||
A stream is an abstract interface implemented by various objects in |
|||
Node. For example a request to an HTTP server is a stream, as is |
|||
stdout. Streams are readable, writable, or both. All streams are |
|||
instances of [EventEmitter][] |
|||
|
|||
You can load the Stream base classes by doing `require('stream')`. |
|||
There are base classes provided for Readable streams, Writable |
|||
streams, Duplex streams, and Transform streams. |
|||
|
|||
## Compatibility |
|||
|
|||
In earlier versions of Node, the Readable stream interface was |
|||
simpler, but also less powerful and less useful. |
|||
|
|||
* Rather than waiting for you to call the `read()` method, `'data'` |
|||
events would start emitting immediately. If you needed to do some |
|||
I/O to decide how to handle data, then you had to store the chunks |
|||
in some kind of buffer so that they would not be lost. |
|||
* The `pause()` method was advisory, rather than guaranteed. This |
|||
meant that you still had to be prepared to receive `'data'` events |
|||
even when the stream was in a paused state. |
|||
|
|||
In Node v0.10, the Readable class described below was added. For |
|||
backwards compatibility with older Node programs, Readable streams |
|||
switch into "old mode" when a `'data'` event handler is added, or when |
|||
the `pause()` or `resume()` methods are called. The effect is that, |
|||
even if you are not using the new `read()` method and `'readable'` |
|||
event, you no longer have to worry about losing `'data'` chunks. |
|||
|
|||
Most programs will continue to function normally. However, this |
|||
introduces an edge case in the following conditions: |
|||
|
|||
* No `'data'` event handler is added. |
|||
* The `pause()` and `resume()` methods are never called. |
|||
|
|||
For example, consider the following code: |
|||
|
|||
```javascript |
|||
// WARNING! BROKEN! |
|||
net.createServer(function(socket) { |
|||
|
|||
// we add an 'end' method, but never consume the data |
|||
socket.on('end', function() { |
|||
// It will never get here. |
|||
socket.end('I got your message (but didnt read it)\n'); |
|||
}); |
|||
|
|||
}).listen(1337); |
|||
``` |
|||
|
|||
In versions of node prior to v0.10, the incoming message data would be |
|||
simply discarded. However, in Node v0.10 and beyond, the socket will |
|||
remain paused forever. |
|||
|
|||
The workaround in this situation is to call the `resume()` method to |
|||
trigger "old mode" behavior: |
|||
|
|||
```javascript |
|||
// Workaround |
|||
net.createServer(function(socket) { |
|||
|
|||
socket.on('end', function() { |
|||
socket.end('I got your message (but didnt read it)\n'); |
|||
}); |
|||
|
|||
// start the flow of data, discarding it. |
|||
socket.resume(); |
|||
|
|||
}).listen(1337); |
|||
``` |
|||
|
|||
In addition to new Readable streams switching into old-mode, pre-v0.10 |
|||
style streams can be wrapped in a Readable class using the `wrap()` |
|||
method. |
|||
|
|||
## Class: stream.Readable |
|||
|
|||
<!--type=class--> |
|||
|
|||
A `Readable Stream` has the following methods, members, and events. |
|||
|
|||
Note that `stream.Readable` is an abstract class designed to be |
|||
extended with an underlying implementation of the `_read(size)` |
|||
method. (See below.) |
|||
|
|||
### new stream.Readable([options]) |
|||
|
|||
* `options` {Object} |
|||
* `highWaterMark` {Number} The maximum number of bytes to store in |
|||
the internal buffer before ceasing to read from the underlying |
|||
resource. Default=16kb |
|||
* `encoding` {String} If specified, then buffers will be decoded to |
|||
strings using the specified encoding. Default=null |
|||
* `objectMode` {Boolean} Whether this stream should behave |
|||
as a stream of objects. Meaning that stream.read(n) returns |
|||
a single value instead of a Buffer of size n |
|||
|
|||
In classes that extend the Readable class, make sure to call the |
|||
constructor so that the buffering settings can be properly |
|||
initialized. |
|||
|
|||
### readable.\_read(size) |
|||
|
|||
* `size` {Number} Number of bytes to read asynchronously |
|||
|
|||
Note: **This function should NOT be called directly.** It should be |
|||
implemented by child classes, and called by the internal Readable |
|||
class methods only. |
|||
|
|||
All Readable stream implementations must provide a `_read` method |
|||
to fetch data from the underlying resource. |
|||
|
|||
This method is prefixed with an underscore because it is internal to |
|||
the class that defines it, and should not be called directly by user |
|||
programs. However, you **are** expected to override this method in |
|||
your own extension classes. |
|||
|
|||
When data is available, put it into the read queue by calling |
|||
`readable.push(chunk)`. If `push` returns false, then you should stop |
|||
reading. When `_read` is called again, you should start pushing more |
|||
data. |
|||
|
|||
The `size` argument is advisory. Implementations where a "read" is a |
|||
single call that returns data can use this to know how much data to |
|||
fetch. Implementations where that is not relevant, such as TCP or |
|||
TLS, may ignore this argument, and simply provide data whenever it |
|||
becomes available. There is no need, for example to "wait" until |
|||
`size` bytes are available before calling `stream.push(chunk)`. |
|||
|
|||
### readable.push(chunk) |
|||
|
|||
* `chunk` {Buffer | null | String} Chunk of data to push into the read queue |
|||
* return {Boolean} Whether or not more pushes should be performed |
|||
|
|||
Note: **This function should be called by Readable implementors, NOT |
|||
by consumers of Readable subclasses.** The `_read()` function will not |
|||
be called again until at least one `push(chunk)` call is made. If no |
|||
data is available, then you MAY call `push('')` (an empty string) to |
|||
allow a future `_read` call, without adding any data to the queue. |
|||
|
|||
The `Readable` class works by putting data into a read queue to be |
|||
pulled out later by calling the `read()` method when the `'readable'` |
|||
event fires. |
|||
|
|||
The `push()` method will explicitly insert some data into the read |
|||
queue. If it is called with `null` then it will signal the end of the |
|||
data. |
|||
|
|||
In some cases, you may be wrapping a lower-level source which has some |
|||
sort of pause/resume mechanism, and a data callback. In those cases, |
|||
you could wrap the low-level source object by doing something like |
|||
this: |
|||
|
|||
```javascript |
|||
// source is an object with readStop() and readStart() methods, |
|||
// and an `ondata` member that gets called when it has data, and |
|||
// an `onend` member that gets called when the data is over. |
|||
|
|||
var stream = new Readable(); |
|||
|
|||
source.ondata = function(chunk) { |
|||
// if push() returns false, then we need to stop reading from source |
|||
if (!stream.push(chunk)) |
|||
source.readStop(); |
|||
}; |
|||
|
|||
source.onend = function() { |
|||
stream.push(null); |
|||
}; |
|||
|
|||
// _read will be called when the stream wants to pull more data in |
|||
// the advisory size argument is ignored in this case. |
|||
stream._read = function(n) { |
|||
source.readStart(); |
|||
}; |
|||
``` |
|||
|
|||
### readable.unshift(chunk) |
|||
|
|||
* `chunk` {Buffer | null | String} Chunk of data to unshift onto the read queue |
|||
* return {Boolean} Whether or not more pushes should be performed |
|||
|
|||
This is the corollary of `readable.push(chunk)`. Rather than putting |
|||
the data at the *end* of the read queue, it puts it at the *front* of |
|||
the read queue. |
|||
|
|||
This is useful in certain use-cases where a stream is being consumed |
|||
by a parser, which needs to "un-consume" some data that it has |
|||
optimistically pulled out of the source. |
|||
|
|||
```javascript |
|||
// A parser for a simple data protocol. |
|||
// The "header" is a JSON object, followed by 2 \n characters, and |
|||
// then a message body. |
|||
// |
|||
// Note: This can be done more simply as a Transform stream. See below. |
|||
|
|||
function SimpleProtocol(source, options) { |
|||
if (!(this instanceof SimpleProtocol)) |
|||
return new SimpleProtocol(options); |
|||
|
|||
Readable.call(this, options); |
|||
this._inBody = false; |
|||
this._sawFirstCr = false; |
|||
|
|||
// source is a readable stream, such as a socket or file |
|||
this._source = source; |
|||
|
|||
var self = this; |
|||
source.on('end', function() { |
|||
self.push(null); |
|||
}); |
|||
|
|||
// give it a kick whenever the source is readable |
|||
// read(0) will not consume any bytes |
|||
source.on('readable', function() { |
|||
self.read(0); |
|||
}); |
|||
|
|||
this._rawHeader = []; |
|||
this.header = null; |
|||
} |
|||
|
|||
SimpleProtocol.prototype = Object.create( |
|||
Readable.prototype, { constructor: { value: SimpleProtocol }}); |
|||
|
|||
SimpleProtocol.prototype._read = function(n) { |
|||
if (!this._inBody) { |
|||
var chunk = this._source.read(); |
|||
|
|||
// if the source doesn't have data, we don't have data yet. |
|||
if (chunk === null) |
|||
return this.push(''); |
|||
|
|||
// check if the chunk has a \n\n |
|||
var split = -1; |
|||
for (var i = 0; i < chunk.length; i++) { |
|||
if (chunk[i] === 10) { // '\n' |
|||
if (this._sawFirstCr) { |
|||
split = i; |
|||
break; |
|||
} else { |
|||
this._sawFirstCr = true; |
|||
} |
|||
} else { |
|||
this._sawFirstCr = false; |
|||
} |
|||
} |
|||
|
|||
if (split === -1) { |
|||
// still waiting for the \n\n |
|||
// stash the chunk, and try again. |
|||
this._rawHeader.push(chunk); |
|||
this.push(''); |
|||
} else { |
|||
this._inBody = true; |
|||
var h = chunk.slice(0, split); |
|||
this._rawHeader.push(h); |
|||
var header = Buffer.concat(this._rawHeader).toString(); |
|||
try { |
|||
this.header = JSON.parse(header); |
|||
} catch (er) { |
|||
this.emit('error', new Error('invalid simple protocol data')); |
|||
return; |
|||
} |
|||
// now, because we got some extra data, unshift the rest |
|||
// back into the read queue so that our consumer will see it. |
|||
var b = chunk.slice(split); |
|||
this.unshift(b); |
|||
|
|||
// and let them know that we are done parsing the header. |
|||
this.emit('header', this.header); |
|||
} |
|||
} else { |
|||
// from there on, just provide the data to our consumer. |
|||
// careful not to push(null), since that would indicate EOF. |
|||
var chunk = this._source.read(); |
|||
if (chunk) this.push(chunk); |
|||
} |
|||
}; |
|||
|
|||
// Usage: |
|||
var parser = new SimpleProtocol(source); |
|||
// Now parser is a readable stream that will emit 'header' |
|||
// with the parsed header data. |
|||
``` |
|||
|
|||
### readable.wrap(stream) |
|||
|
|||
* `stream` {Stream} An "old style" readable stream |
|||
|
|||
If you are using an older Node library that emits `'data'` events and |
|||
has a `pause()` method that is advisory only, then you can use the |
|||
`wrap()` method to create a Readable stream that uses the old stream |
|||
as its data source. |
|||
|
|||
For example: |
|||
|
|||
```javascript |
|||
var OldReader = require('./old-api-module.js').OldReader; |
|||
var oreader = new OldReader; |
|||
var Readable = require('stream').Readable; |
|||
var myReader = new Readable().wrap(oreader); |
|||
|
|||
myReader.on('readable', function() { |
|||
myReader.read(); // etc. |
|||
}); |
|||
``` |
|||
|
|||
### Event: 'readable' |
|||
|
|||
When there is data ready to be consumed, this event will fire. |
|||
|
|||
When this event emits, call the `read()` method to consume the data. |
|||
|
|||
### Event: 'end' |
|||
|
|||
Emitted when the stream has received an EOF (FIN in TCP terminology). |
|||
Indicates that no more `'data'` events will happen. If the stream is |
|||
also writable, it may be possible to continue writing. |
|||
|
|||
### Event: 'data' |
|||
|
|||
The `'data'` event emits either a `Buffer` (by default) or a string if |
|||
`setEncoding()` was used. |
|||
|
|||
Note that adding a `'data'` event listener will switch the Readable |
|||
stream into "old mode", where data is emitted as soon as it is |
|||
available, rather than waiting for you to call `read()` to consume it. |
|||
|
|||
### Event: 'error' |
|||
|
|||
Emitted if there was an error receiving data. |
|||
|
|||
### Event: 'close' |
|||
|
|||
Emitted when the underlying resource (for example, the backing file |
|||
descriptor) has been closed. Not all streams will emit this. |
|||
|
|||
### readable.setEncoding(encoding) |
|||
|
|||
Makes the `'data'` event emit a string instead of a `Buffer`. `encoding` |
|||
can be `'utf8'`, `'utf16le'` (`'ucs2'`), `'ascii'`, or `'hex'`. |
|||
|
|||
The encoding can also be set by specifying an `encoding` field to the |
|||
constructor. |
|||
|
|||
### readable.read([size]) |
|||
|
|||
* `size` {Number | null} Optional number of bytes to read. |
|||
* Return: {Buffer | String | null} |
|||
|
|||
Note: **This function SHOULD be called by Readable stream users.** |
|||
|
|||
Call this method to consume data once the `'readable'` event is |
|||
emitted. |
|||
|
|||
The `size` argument will set a minimum number of bytes that you are |
|||
interested in. If not set, then the entire content of the internal |
|||
buffer is returned. |
|||
|
|||
If there is no data to consume, or if there are fewer bytes in the |
|||
internal buffer than the `size` argument, then `null` is returned, and |
|||
a future `'readable'` event will be emitted when more is available. |
|||
|
|||
Calling `stream.read(0)` will always return `null`, and will trigger a |
|||
refresh of the internal buffer, but otherwise be a no-op. |
|||
|
|||
### readable.pipe(destination, [options]) |
|||
|
|||
* `destination` {Writable Stream} |
|||
* `options` {Object} Optional |
|||
* `end` {Boolean} Default=true |
|||
|
|||
Connects this readable stream to `destination` WriteStream. Incoming |
|||
data on this stream gets written to `destination`. Properly manages |
|||
back-pressure so that a slow destination will not be overwhelmed by a |
|||
fast readable stream. |
|||
|
|||
This function returns the `destination` stream. |
|||
|
|||
For example, emulating the Unix `cat` command: |
|||
|
|||
process.stdin.pipe(process.stdout); |
|||
|
|||
By default `end()` is called on the destination when the source stream |
|||
emits `end`, so that `destination` is no longer writable. Pass `{ end: |
|||
false }` as `options` to keep the destination stream open. |
|||
|
|||
This keeps `writer` open so that "Goodbye" can be written at the |
|||
end. |
|||
|
|||
reader.pipe(writer, { end: false }); |
|||
reader.on("end", function() { |
|||
writer.end("Goodbye\n"); |
|||
}); |
|||
|
|||
Note that `process.stderr` and `process.stdout` are never closed until |
|||
the process exits, regardless of the specified options. |
|||
|
|||
### readable.unpipe([destination]) |
|||
|
|||
* `destination` {Writable Stream} Optional |
|||
|
|||
Undo a previously established `pipe()`. If no destination is |
|||
provided, then all previously established pipes are removed. |
|||
|
|||
### readable.pause() |
|||
|
|||
Switches the readable stream into "old mode", where data is emitted |
|||
using a `'data'` event rather than being buffered for consumption via |
|||
the `read()` method. |
|||
|
|||
Ceases the flow of data. No `'data'` events are emitted while the |
|||
stream is in a paused state. |
|||
|
|||
### readable.resume() |
|||
|
|||
Switches the readable stream into "old mode", where data is emitted |
|||
using a `'data'` event rather than being buffered for consumption via |
|||
the `read()` method. |
|||
|
|||
Resumes the incoming `'data'` events after a `pause()`. |
|||
|
|||
|
|||
## Class: stream.Writable |
|||
|
|||
<!--type=class--> |
|||
|
|||
A `Writable` Stream has the following methods, members, and events. |
|||
|
|||
Note that `stream.Writable` is an abstract class designed to be |
|||
extended with an underlying implementation of the |
|||
`_write(chunk, encoding, cb)` method. (See below.) |
|||
|
|||
### new stream.Writable([options]) |
|||
|
|||
* `options` {Object} |
|||
* `highWaterMark` {Number} Buffer level when `write()` starts |
|||
returning false. Default=16kb |
|||
* `decodeStrings` {Boolean} Whether or not to decode strings into |
|||
Buffers before passing them to `_write()`. Default=true |
|||
|
|||
In classes that extend the Writable class, make sure to call the |
|||
constructor so that the buffering settings can be properly |
|||
initialized. |
|||
|
|||
### writable.\_write(chunk, encoding, callback) |
|||
|
|||
* `chunk` {Buffer | String} The chunk to be written. Will always |
|||
be a buffer unless the `decodeStrings` option was set to `false`. |
|||
* `encoding` {String} If the chunk is a string, then this is the |
|||
encoding type. Ignore chunk is a buffer. Note that chunk will |
|||
**always** be a buffer unless the `decodeStrings` option is |
|||
explicitly set to `false`. |
|||
* `callback` {Function} Call this function (optionally with an error |
|||
argument) when you are done processing the supplied chunk. |
|||
|
|||
All Writable stream implementations must provide a `_write` method to |
|||
send data to the underlying resource. |
|||
|
|||
Note: **This function MUST NOT be called directly.** It should be |
|||
implemented by child classes, and called by the internal Writable |
|||
class methods only. |
|||
|
|||
Call the callback using the standard `callback(error)` pattern to |
|||
signal that the write completed successfully or with an error. |
|||
|
|||
If the `decodeStrings` flag is set in the constructor options, then |
|||
`chunk` may be a string rather than a Buffer, and `encoding` will |
|||
indicate the sort of string that it is. This is to support |
|||
implementations that have an optimized handling for certain string |
|||
data encodings. If you do not explicitly set the `decodeStrings` |
|||
option to `false`, then you can safely ignore the `encoding` argument, |
|||
and assume that `chunk` will always be a Buffer. |
|||
|
|||
This method is prefixed with an underscore because it is internal to |
|||
the class that defines it, and should not be called directly by user |
|||
programs. However, you **are** expected to override this method in |
|||
your own extension classes. |
|||
|
|||
|
|||
### writable.write(chunk, [encoding], [callback]) |
|||
|
|||
* `chunk` {Buffer | String} Data to be written |
|||
* `encoding` {String} Optional. If `chunk` is a string, then encoding |
|||
defaults to `'utf8'` |
|||
* `callback` {Function} Optional. Called when this chunk is |
|||
successfully written. |
|||
* Returns {Boolean} |
|||
|
|||
Writes `chunk` to the stream. Returns `true` if the data has been |
|||
flushed to the underlying resource. Returns `false` to indicate that |
|||
the buffer is full, and the data will be sent out in the future. The |
|||
`'drain'` event will indicate when the buffer is empty again. |
|||
|
|||
The specifics of when `write()` will return false, is determined by |
|||
the `highWaterMark` option provided to the constructor. |
|||
|
|||
### writable.end([chunk], [encoding], [callback]) |
|||
|
|||
* `chunk` {Buffer | String} Optional final data to be written |
|||
* `encoding` {String} Optional. If `chunk` is a string, then encoding |
|||
defaults to `'utf8'` |
|||
* `callback` {Function} Optional. Called when the final chunk is |
|||
successfully written. |
|||
|
|||
Call this method to signal the end of the data being written to the |
|||
stream. |
|||
|
|||
### Event: 'drain' |
|||
|
|||
Emitted when the stream's write queue empties and it's safe to write |
|||
without buffering again. Listen for it when `stream.write()` returns |
|||
`false`. |
|||
|
|||
### Event: 'close' |
|||
|
|||
Emitted when the underlying resource (for example, the backing file |
|||
descriptor) has been closed. Not all streams will emit this. |
|||
|
|||
### Event: 'finish' |
|||
|
|||
When `end()` is called and there are no more chunks to write, this |
|||
event is emitted. |
|||
|
|||
### Event: 'pipe' |
|||
|
|||
* `source` {Readable Stream} |
|||
|
|||
Emitted when the stream is passed to a readable stream's pipe method. |
|||
|
|||
### Event 'unpipe' |
|||
|
|||
* `source` {Readable Stream} |
|||
|
|||
Emitted when a previously established `pipe()` is removed using the |
|||
source Readable stream's `unpipe()` method. |
|||
|
|||
## Class: stream.Duplex |
|||
|
|||
<!--type=class--> |
|||
|
|||
A "duplex" stream is one that is both Readable and Writable, such as a |
|||
TCP socket connection. |
|||
|
|||
Note that `stream.Duplex` is an abstract class designed to be |
|||
extended with an underlying implementation of the `_read(size)` |
|||
and `_write(chunk, encoding, callback)` methods as you would with a Readable or |
|||
Writable stream class. |
|||
|
|||
Since JavaScript doesn't have multiple prototypal inheritance, this |
|||
class prototypally inherits from Readable, and then parasitically from |
|||
Writable. It is thus up to the user to implement both the lowlevel |
|||
`_read(n)` method as well as the lowlevel `_write(chunk, encoding, cb)` method |
|||
on extension duplex classes. |
|||
|
|||
### new stream.Duplex(options) |
|||
|
|||
* `options` {Object} Passed to both Writable and Readable |
|||
constructors. Also has the following fields: |
|||
* `allowHalfOpen` {Boolean} Default=true. If set to `false`, then |
|||
the stream will automatically end the readable side when the |
|||
writable side ends and vice versa. |
|||
|
|||
In classes that extend the Duplex class, make sure to call the |
|||
constructor so that the buffering settings can be properly |
|||
initialized. |
|||
|
|||
## Class: stream.Transform |
|||
|
|||
A "transform" stream is a duplex stream where the output is causally |
|||
connected in some way to the input, such as a zlib stream or a crypto |
|||
stream. |
|||
|
|||
There is no requirement that the output be the same size as the input, |
|||
the same number of chunks, or arrive at the same time. For example, a |
|||
Hash stream will only ever have a single chunk of output which is |
|||
provided when the input is ended. A zlib stream will either produce |
|||
much smaller or much larger than its input. |
|||
|
|||
Rather than implement the `_read()` and `_write()` methods, Transform |
|||
classes must implement the `_transform()` method, and may optionally |
|||
also implement the `_flush()` method. (See below.) |
|||
|
|||
### new stream.Transform([options]) |
|||
|
|||
* `options` {Object} Passed to both Writable and Readable |
|||
constructors. |
|||
|
|||
In classes that extend the Transform class, make sure to call the |
|||
constructor so that the buffering settings can be properly |
|||
initialized. |
|||
|
|||
### transform.\_transform(chunk, encoding, callback) |
|||
|
|||
* `chunk` {Buffer | String} The chunk to be transformed. Will always |
|||
be a buffer unless the `decodeStrings` option was set to `false`. |
|||
* `encoding` {String} If the chunk is a string, then this is the |
|||
encoding type. (Ignore if `decodeStrings` chunk is a buffer.) |
|||
* `callback` {Function} Call this function (optionally with an error |
|||
argument) when you are done processing the supplied chunk. |
|||
|
|||
Note: **This function MUST NOT be called directly.** It should be |
|||
implemented by child classes, and called by the internal Transform |
|||
class methods only. |
|||
|
|||
All Transform stream implementations must provide a `_transform` |
|||
method to accept input and produce output. |
|||
|
|||
`_transform` should do whatever has to be done in this specific |
|||
Transform class, to handle the bytes being written, and pass them off |
|||
to the readable portion of the interface. Do asynchronous I/O, |
|||
process things, and so on. |
|||
|
|||
Call `transform.push(outputChunk)` 0 or more times to generate output |
|||
from this input chunk, depending on how much data you want to output |
|||
as a result of this chunk. |
|||
|
|||
Call the callback function only when the current chunk is completely |
|||
consumed. Note that there may or may not be output as a result of any |
|||
particular input chunk. |
|||
|
|||
This method is prefixed with an underscore because it is internal to |
|||
the class that defines it, and should not be called directly by user |
|||
programs. However, you **are** expected to override this method in |
|||
your own extension classes. |
|||
|
|||
### transform.\_flush(callback) |
|||
|
|||
* `callback` {Function} Call this function (optionally with an error |
|||
argument) when you are done flushing any remaining data. |
|||
|
|||
Note: **This function MUST NOT be called directly.** It MAY be implemented |
|||
by child classes, and if so, will be called by the internal Transform |
|||
class methods only. |
|||
|
|||
In some cases, your transform operation may need to emit a bit more |
|||
data at the end of the stream. For example, a `Zlib` compression |
|||
stream will store up some internal state so that it can optimally |
|||
compress the output. At the end, however, it needs to do the best it |
|||
can with what is left, so that the data will be complete. |
|||
|
|||
In those cases, you can implement a `_flush` method, which will be |
|||
called at the very end, after all the written data is consumed, but |
|||
before emitting `end` to signal the end of the readable side. Just |
|||
like with `_transform`, call `transform.push(chunk)` zero or more |
|||
times, as appropriate, and call `callback` when the flush operation is |
|||
complete. |
|||
|
|||
This method is prefixed with an underscore because it is internal to |
|||
the class that defines it, and should not be called directly by user |
|||
programs. However, you **are** expected to override this method in |
|||
your own extension classes. |
|||
|
|||
### Example: `SimpleProtocol` parser |
|||
|
|||
The example above of a simple protocol parser can be implemented much |
|||
more simply by using the higher level `Transform` stream class. |
|||
|
|||
In this example, rather than providing the input as an argument, it |
|||
would be piped into the parser, which is a more idiomatic Node stream |
|||
approach. |
|||
|
|||
```javascript |
|||
function SimpleProtocol(options) { |
|||
if (!(this instanceof SimpleProtocol)) |
|||
return new SimpleProtocol(options); |
|||
|
|||
Transform.call(this, options); |
|||
this._inBody = false; |
|||
this._sawFirstCr = false; |
|||
this._rawHeader = []; |
|||
this.header = null; |
|||
} |
|||
|
|||
SimpleProtocol.prototype = Object.create( |
|||
Transform.prototype, { constructor: { value: SimpleProtocol }}); |
|||
|
|||
SimpleProtocol.prototype._transform = function(chunk, encoding, done) { |
|||
if (!this._inBody) { |
|||
// check if the chunk has a \n\n |
|||
var split = -1; |
|||
for (var i = 0; i < chunk.length; i++) { |
|||
if (chunk[i] === 10) { // '\n' |
|||
if (this._sawFirstCr) { |
|||
split = i; |
|||
break; |
|||
} else { |
|||
this._sawFirstCr = true; |
|||
} |
|||
} else { |
|||
this._sawFirstCr = false; |
|||
} |
|||
} |
|||
|
|||
if (split === -1) { |
|||
// still waiting for the \n\n |
|||
// stash the chunk, and try again. |
|||
this._rawHeader.push(chunk); |
|||
} else { |
|||
this._inBody = true; |
|||
var h = chunk.slice(0, split); |
|||
this._rawHeader.push(h); |
|||
var header = Buffer.concat(this._rawHeader).toString(); |
|||
try { |
|||
this.header = JSON.parse(header); |
|||
} catch (er) { |
|||
this.emit('error', new Error('invalid simple protocol data')); |
|||
return; |
|||
} |
|||
// and let them know that we are done parsing the header. |
|||
this.emit('header', this.header); |
|||
|
|||
// now, because we got some extra data, emit this first. |
|||
this.push(b); |
|||
} |
|||
} else { |
|||
// from there on, just provide the data to our consumer as-is. |
|||
this.push(b); |
|||
} |
|||
done(); |
|||
}; |
|||
|
|||
var parser = new SimpleProtocol(); |
|||
source.pipe(parser) |
|||
|
|||
// Now parser is a readable stream that will emit 'header' |
|||
// with the parsed header data. |
|||
``` |
|||
|
|||
|
|||
## Class: stream.PassThrough |
|||
|
|||
This is a trivial implementation of a `Transform` stream that simply |
|||
passes the input bytes across to the output. Its purpose is mainly |
|||
for examples and testing, but there are occasionally use cases where |
|||
it can come in handy. |
|||
|
|||
|
|||
[EventEmitter]: http://nodejs.org/api/events.html#events_class_events_eventemitter |
|||
@ -1,89 +0,0 @@ |
|||
title: multi-server continuous deployment with fleet |
|||
author: Isaac Schlueter |
|||
date: Wed May 02 2012 11:00:00 GMT-0700 (PDT) |
|||
status: publish |
|||
category: module |
|||
slug: multi-server-continuous-deployment-with-fleet |
|||
|
|||
<p><img style="float:right;margin-left:1.2em;" alt="substack" src="http://substack.net/images/substackistan.png"><i>This is a guest post by James "SubStack" Halliday, originally posted <a href="http://substack.net/posts/16a9d8/multi-server-continuous-deployment-with-fleet">on his blog</a>, and reposted here with permission.</i></p> |
|||
|
|||
<p>Writing applications as a sequence of tiny services that all talk to each other over the network has many upsides, but it can be annoyingly tedious to get all the subsystems up and running. </p> |
|||
|
|||
<p>Running a <a href="http://substack.net/posts/7a1c42">seaport</a> can help with getting all the services to talk to each other, but running the processes is another matter, especially when you have new code to push into production. </p> |
|||
|
|||
<p><a href="http://github.com/substack/fleet">fleet</a> aims to make it really easy for anyone on your team to push new code from git to an armada of servers and manage all the processes in your stack. </p> |
|||
|
|||
<p>To start using fleet, just install the fleet command with <a href="http://npmjs.org">npm</a>: </p> |
|||
|
|||
<pre style="">npm install -g fleet </pre> |
|||
|
|||
<p>Then on one of your servers, start a fleet hub. From a fresh directory, give it a passphrase and a port to listen on: </p> |
|||
|
|||
<pre style="">fleet hub --port=7000 --secret=beepboop </pre> |
|||
|
|||
<p>Now fleet is listening on :7000 for commands and has started a git server on :7001 over http. There's no ssh keys or post commit hooks to configure, just run that command and you're ready to go! </p> |
|||
|
|||
<p>Next set up some worker drones to run your processes. You can have as many workers as you like on a single server but each worker should be run from a separate directory. Just do: </p> |
|||
|
|||
<pre style="">fleet drone --hub=x.x.x.x:7000 --secret=beepboop </pre> |
|||
|
|||
<p>where <span class="code">x.x.x.x</span> is the address where the fleet hub is running. Spin up a few of these drones. </p> |
|||
|
|||
<p>Now navigate to the directory of the app you want to deploy. First set a remote so you don't need to type <span class="code">--hub</span> and <span class="code">--secret</span> all the time. </p> |
|||
|
|||
<pre style="">fleet remote add default --hub=x.x.x.x:7000 --secret=beepboop </pre> |
|||
|
|||
<p>Fleet just created a <span class="code">fleet.json</span> file for you to save your settings. </p> |
|||
|
|||
<p>From the same app directory, to deploy your code just do: </p> |
|||
|
|||
<pre style="">fleet deploy </pre> |
|||
|
|||
<p>The deploy command does a <span class="code">git push</span> to the fleet hub's git http server and then the hub instructs all the drones to pull from it. Your code gets checked out into a new directory on all the fleet drones every time you deploy. </p> |
|||
|
|||
<p>Because fleet is designed specifically for managing applications with lots of tiny services, the deploy command isn't tied to running any processes. Starting processes is up to the programmer but it's super simple. Just use the <span class="code">fleet spawn</span> command: </p> |
|||
|
|||
<pre style="">fleet spawn -- node server.js 8080 </pre> |
|||
|
|||
<p>By default fleet picks a drone at random to run the process on. You can specify which drone you want to run a particular process on with the <span class="code">--drone</span> switch if it matters. </p> |
|||
|
|||
<p>Start a few processes across all your worker drones and then show what is running with the <span class="code">fleet ps</span> command: </p> |
|||
|
|||
<pre style="">fleet ps |
|||
drone#3dfe17b8 |
|||
├─┬ pid#1e99f4 |
|||
│ ├── status: running |
|||
│ ├── commit: webapp/1b8050fcaf8f1b02b9175fcb422644cb67dc8cc5 |
|||
│ └── command: node server.js 8888 |
|||
└─┬ pid#d7048a |
|||
├── status: running |
|||
├── commit: webapp/1b8050fcaf8f1b02b9175fcb422644cb67dc8cc5 |
|||
└── command: node server.js 8889</pre> |
|||
|
|||
<p>Now suppose that you have new code to push out into production. By default, fleet lets you spin up new services without disturbing your existing services. If you <span class="code">fleet deploy</span> again after checking in some new changes to git, the next time you <span class="code">fleet spawn</span> a new process, that process will be spun up in a completely new directory based on the git commit hash. To stop a process, just use <span class="code">fleet stop</span>. </p> |
|||
|
|||
<p>This approach lets you verify that the new services work before bringing down the old services. You can even start experimenting with heterogeneous and incremental deployment by hooking into a custom <a href="http://substack.net/posts/5bd18d">http proxy</a>! </p> |
|||
|
|||
<p>Even better, if you use a service registry like <a href="http://substack.net/posts/7a1c42">seaport</a> for managing the host/port tables, you can spin up new ad-hoc staging clusters all the time without disrupting the normal operation of your site before rolling out new code to users. </p> |
|||
|
|||
<p>Fleet has many more commands that you can learn about with its git-style manpage-based help system! Just do <span class="code">fleet help</span> to get a list of all the commands you can run. </p> |
|||
|
|||
<pre style="">fleet help |
|||
Usage: fleet <command> [<args>] |
|||
|
|||
The commands are: |
|||
deploy Push code to drones. |
|||
drone Connect to a hub as a worker. |
|||
exec Run commands on drones. |
|||
hub Create a hub for drones to connect. |
|||
monitor Show service events system-wide. |
|||
ps List the running processes on the drones. |
|||
remote Manage the set of remote hubs. |
|||
spawn Run services on drones. |
|||
stop Stop processes running on drones. |
|||
|
|||
For help about a command, try `fleet help `.</pre> |
|||
|
|||
<p><span class="code">npm install -g fleet</span> and <a href="https://github.com/substack/fleet">check out the code on github</a>! </p> |
|||
|
|||
<img src="http://substack.net/images/fleet.png" width="849" height="568"> |
|||
@ -1,337 +0,0 @@ |
|||
title: Service logging in JSON with Bunyan |
|||
author: trentmick |
|||
date: Wed Mar 28 2012 12:25:26 GMT-0700 (PDT) |
|||
status: publish |
|||
category: module |
|||
slug: service-logging-in-json-with-bunyan |
|||
|
|||
<div style="float:right;margin:0 0 15px 15px;"> |
|||
<img class="alignnone size-full wp-image-469" title="Bunyan" src="http://nodeblog.files.wordpress.com/2012/03/bunyan.png" alt="Paul Bunyan and Babe the Blue Ox" width="240" height="320" /><br /> |
|||
<a href="http://www.flickr.com/photos/stublag/2876034487">Photo by Paul Carroll</a> |
|||
</div> |
|||
|
|||
<p>Service logs are gold, if you can mine them. We scan them for occasional debugging. Perhaps we grep them looking for errors or warnings, or setup an occasional nagios log regex monitor. If that. This is a waste of the best channel for data about a service.</p> |
|||
|
|||
<p><a href="http://www.youtube.com/watch?v=01-2pNCZiNk">"Log. (Huh) What is it good for. Absolutely ..."</a></p> |
|||
|
|||
<ul> |
|||
<li>debugging</li> |
|||
<li>monitors tools that alert operators</li> |
|||
<li>non real-time analysis (business or operational analysis)</li> |
|||
<li>historical analysis</li> |
|||
</ul> |
|||
|
|||
<p>These are what logs are good for. The current state of logging is barely adequate for the first of these. Doing reliable analysis, and even monitoring, of varied <a href="http://journal.paul.querna.org/articles/2011/12/26/log-for-machines-in-json/">"printf-style" logs</a> is a grueling or hacky task that most either don't bother with, fallback to paying someone else to do (viz. Splunk's great successes), or, for web sites, punt and use the plethora of JavaScript-based web analytics tools.</p> |
|||
|
|||
<p>Let's log in JSON. Let's format log records with a filter <em>outside</em> the app. Let's put more info in log records by not shoehorning into a printf-message. Debuggability can be improved. Monitoring and analysis can <em>definitely</em> be improved. Let's <em>not</em> write another regex-based parser, and use the time we've saved writing tools to collate logs from multiple nodes and services, to query structured logs (from all services, not just web servers), etc.</p> |
|||
|
|||
<p>At <a href="http://joyent.com">Joyent</a> we use node.js for running many core services -- loosely coupled through HTTP REST APIs and/or AMQP. In this post I'll draw on experiences from my work on Joyent's <a href="http://www.joyent.com/products/smartdatacenter/">SmartDataCenter product</a> and observations of <a href="http://www.joyentcloud.com/">Joyent Cloud</a> operations to suggest some improvements to service logging. I'll show the (open source) <strong>Bunyan logging library and tool</strong> that we're developing to improve the logging toolchain.</p> |
|||
|
|||
<h1 style="margin:48px 0 24px;" id="current-state-of-log-formatting">Current State of Log Formatting</h1> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code># apache access log |
|||
10.0.1.22 - - [15/Oct/2010:11:46:46 -0700] "GET /favicon.ico HTTP/1.1" 404 209 |
|||
fe80::6233:4bff:fe29:3173 - - [15/Oct/2010:11:46:58 -0700] "GET / HTTP/1.1" 200 44 |
|||
|
|||
# apache error log |
|||
[Fri Oct 15 11:46:46 2010] [error] [client 10.0.1.22] File does not exist: /Library/WebServer/Documents/favicon.ico |
|||
[Fri Oct 15 11:46:58 2010] [error] [client fe80::6233:4bff:fe29:3173] File does not exist: /Library/WebServer/Documents/favicon.ico |
|||
|
|||
# Mac /var/log/secure.log |
|||
Oct 14 09:20:56 banana loginwindow[41]: in pam_sm_authenticate(): Failed to determine Kerberos principal name. |
|||
Oct 14 12:32:20 banana com.apple.SecurityServer[25]: UID 501 authenticated as user trentm (UID 501) for right 'system.privilege.admin' |
|||
|
|||
# an internal joyent agent log |
|||
[2012-02-07 00:37:11.898] [INFO] AMQPAgent - Publishing success. |
|||
[2012-02-07 00:37:11.910] [DEBUG] AMQPAgent - { req_id: '8afb8d99-df8e-4724-8535-3d52adaebf25', |
|||
timestamp: '2012-02-07T00:37:11.898Z', |
|||
|
|||
# typical expressjs log output |
|||
[Mon, 21 Nov 2011 20:52:11 GMT] 200 GET /foo (1ms) |
|||
Blah, some other unstructured output to from a console.log call. |
|||
</code></pre> |
|||
|
|||
<p>What're we doing here? Five logs at random. Five different date formats. As <a href="http://journal.paul.querna.org/articles/2011/12/26/log-for-machines-in-json/">Paul Querna points out</a> we haven't improved log parsability in 20 years. Parsability is enemy number one. You can't use your logs until you can parse the records, and faced with the above the inevitable solution is a one-off regular expression.</p> |
|||
|
|||
<p>The current state of the art is various <a href="http://search.cpan.org/~akira/Apache-ParseLog-1.02/ParseLog.pm">parsing libs</a>, <a href="http://www.webalizer.org/">analysis</a> <a href="http://awstats.sourceforge.net/">tools</a> and homebrew scripts ranging from grep to Perl, whose scope is limited to a few niches log formats.</p> |
|||
|
|||
<h1 style="margin:48px 0 24px;" id="json-for-logs">JSON for Logs</h1> |
|||
|
|||
<p><code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">JSON.parse()</code> solves all that. Let's log in JSON. But it means a change in thinking: <strong>The first-level audience for log files shouldn't be a person, but a machine.</strong></p> |
|||
|
|||
<p>That is not said lightly. The "Unix Way" of small focused tools lightly coupled with text output is important. JSON is less "text-y" than, e.g., Apache common log format. JSON makes <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">grep</code> and <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">awk</code> awkward. Using <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">less</code> directly on a log is handy.</p> |
|||
|
|||
<p>But not handy enough. That <a href="http://bit.ly/wTPlN3">80's pastel jumpsuit awkwardness</a> you're feeling isn't the JSON, it's your tools. Time to find a <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">json</code> tool -- <a href="https://github.com/trentm/json">json</a> is one, <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">bunyan</code> described below is another one. Time to learn your JSON library instead of your regex library: <a href="https://developer.mozilla.org/en/JSON">JavaScript</a>, <a href="http://docs.python.org/library/json.html">Python</a>, <a href="http://flori.github.com/json/">Ruby</a>, <a href="http://json.org/java/">Java</a>, <a href="http://search.cpan.org/~makamaka/JSON-2.53/lib/JSON.pm">Perl</a>.</p> |
|||
|
|||
<p>Time to burn your log4j Layout classes and move formatting to the tools side. Creating a log message with semantic information and throwing that away to make a string is silly. The win at being able to trivially parse log records is huge. The possibilities at being able to add ad hoc structured information to individual log records is interesting: think program state metrics, think feeding to Splunk, or loggly, think easy audit logs.</p> |
|||
|
|||
<h1 style="margin:48px 0 24px;" id="introducing-bunyan">Introducing Bunyan</h1> |
|||
|
|||
<p><a href="https://github.com/trentm/node-bunyan">Bunyan</a> is <strong>a node.js module for logging in JSON</strong> and <strong>a <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">bunyan</code> CLI tool</strong> to view those logs.</p> |
|||
|
|||
<p>Logging with Bunyan basically looks like this:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>$ cat hi.js |
|||
var Logger = require('bunyan'); |
|||
var log = new Logger({name: 'hello' /*, ... */}); |
|||
log.info("hi %s", "paul"); |
|||
</code></pre> |
|||
|
|||
<p>And you'll get a log record like this:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>$ node hi.js |
|||
{"name":"hello","hostname":"banana.local","pid":40026,"level":30,"msg":"hi paul","time":"2012-03-28T17:25:37.050Z","v":0} |
|||
</code></pre> |
|||
|
|||
<p>Pipe that through the <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">bunyan</code> tool that is part of the "node-bunyan" install to get more readable output:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>$ node hi.js | ./node_modules/.bin/bunyan # formatted text output |
|||
[2012-02-07T18:50:18.003Z] INFO: hello/40026 on banana.local: hi paul |
|||
|
|||
$ node hi.js | ./node_modules/.bin/bunyan -j # indented JSON output |
|||
{ |
|||
"name": "hello", |
|||
"hostname": "banana.local", |
|||
"pid": 40087, |
|||
"level": 30, |
|||
"msg": "hi paul", |
|||
"time": "2012-03-28T17:26:38.431Z", |
|||
"v": 0 |
|||
} |
|||
</code></pre> |
|||
|
|||
<p>Bunyan is log4j-like: create a Logger with a name, call <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">log.info(...)</code>, etc. However it has no intention of reproducing much of the functionality of log4j. IMO, much of that is overkill for the types of services you'll tend to be writing with node.js.</p> |
|||
|
|||
<h1 style="margin:48px 0 24px;" id="longer-bunyan-example">Longer Bunyan Example</h1> |
|||
|
|||
<p>Let's walk through a bigger example to show some interesting things in Bunyan. We'll create a very small "Hello API" server using the excellent <a href="https://github.com/mcavage/node-restify">restify</a> library -- which we used heavily here at <a href="http://joyent.com">Joyent</a>. (Bunyan doesn't require restify at all, you can easily use Bunyan with <a href="http://expressjs.com/">Express</a> or whatever.)</p> |
|||
|
|||
<p><em>You can follow along in <a href="https://github.com/trentm/hello-json-logging">https://github.com/trentm/hello-json-logging</a> if you like. Note that I'm using the current HEAD of the bunyan and restify trees here, so details might change a bit. Prerequisite: a node 0.6.x installation.</em></p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>git clone https://github.com/trentm/hello-json-logging.git |
|||
cd hello-json-logging |
|||
make |
|||
</code></pre> |
|||
|
|||
<h2 id="bunyan-logger">Bunyan Logger</h2> |
|||
|
|||
<p>Our <a href="https://github.com/trentm/hello-json-logging/blob/master/server.js">server</a> first creates a Bunyan logger:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>var Logger = require('bunyan'); |
|||
var log = new Logger({ |
|||
name: 'helloapi', |
|||
streams: [ |
|||
{ |
|||
stream: process.stdout, |
|||
level: 'debug' |
|||
}, |
|||
{ |
|||
path: 'hello.log', |
|||
level: 'trace' |
|||
} |
|||
], |
|||
serializers: { |
|||
req: Logger.stdSerializers.req, |
|||
res: restify.bunyan.serializers.response, |
|||
}, |
|||
}); |
|||
</code></pre> |
|||
|
|||
<p>Every Bunyan logger must have a <strong>name</strong>. Unlike log4j, this is not a hierarchical dotted namespace. It is just a name field for the log records.</p> |
|||
|
|||
<p>Every Bunyan logger has one or more <strong>streams</strong>, to which log records are written. Here we've defined two: logging at DEBUG level and above is written to stdout, and logging at TRACE and above is appended to 'hello.log'.</p> |
|||
|
|||
<p>Bunyan has the concept of <strong>serializers</strong>: a registry of functions that know how to convert a JavaScript object for a certain log record field to a nice JSON representation for logging. For example, here we register the <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">Logger.stdSerializers.req</code> function to convert HTTP Request objects (using the field name "req") to JSON. More on serializers later.</p> |
|||
|
|||
<h2 id="restify-server">Restify Server</h2> |
|||
|
|||
<p>Restify 1.x and above has bunyan support baked in. You pass in your Bunyan logger like this:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>var server = restify.createServer({ |
|||
name: 'Hello API', |
|||
log: log // Pass our logger to restify. |
|||
}); |
|||
</code></pre> |
|||
|
|||
<p>Our simple API will have a single <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">GET /hello?name=NAME</code> endpoint:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>server.get({path: '/hello', name: 'SayHello'}, function(req, res, next) { |
|||
var caller = req.params.name || 'caller'; |
|||
req.log.debug('caller is "%s"', caller); |
|||
res.send({"hello": caller}); |
|||
return next(); |
|||
}); |
|||
</code></pre> |
|||
|
|||
<p>If we run that, <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">node server.js</code>, and call the endpoint, we get the expected restify response:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>$ curl -iSs http://0.0.0.0:8080/hello?name=paul |
|||
HTTP/1.1 200 OK |
|||
Access-Control-Allow-Origin: * |
|||
Access-Control-Allow-Headers: Accept, Accept-Version, Content-Length, Content-MD5, Content-Type, Date, X-Api-Version |
|||
Access-Control-Expose-Headers: X-Api-Version, X-Request-Id, X-Response-Time |
|||
Server: Hello API |
|||
X-Request-Id: f6aaf942-c60d-4c72-8ddd-bada459db5e3 |
|||
Access-Control-Allow-Methods: GET |
|||
Connection: close |
|||
Content-Length: 16 |
|||
Content-MD5: Xmn3QcFXaIaKw9RPUARGBA== |
|||
Content-Type: application/json |
|||
Date: Tue, 07 Feb 2012 19:12:35 GMT |
|||
X-Response-Time: 4 |
|||
|
|||
{"hello":"paul"} |
|||
</code></pre> |
|||
|
|||
<h2 id="setup-server-logging">Setup Server Logging</h2> |
|||
|
|||
<p>Let's add two things to our server. First, we'll use the <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">server.pre</code> to hook into restify's request handling before routing where we'll <strong>log the request</strong>.</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>server.pre(function (request, response, next) { |
|||
request.log.info({req: request}, 'start'); // (1) |
|||
return next(); |
|||
}); |
|||
</code></pre> |
|||
|
|||
<p>This is the first time we've seen this <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">log.info</code> style with an object as the first argument. Bunyan logging methods (<code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">log.trace</code>, <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">log.debug</code>, ...) all support an optional <strong>first object argument with extra log record fields</strong>:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>log.info(<object> fields, <string> msg, ...) |
|||
</code></pre> |
|||
|
|||
<p>Here we pass in the restify Request object, <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">req</code>. The "req" serializer we registered above will come into play here, but bear with me.</p> |
|||
|
|||
<p>Remember that we already had this debug log statement in our endpoint handler:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>req.log.debug('caller is "%s"', caller); // (2) |
|||
</code></pre> |
|||
|
|||
<p>Second, use the restify server <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">after</code> event to <strong>log the response</strong>:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>server.on('after', function (req, res, route) { |
|||
req.log.info({res: res}, "finished"); // (3) |
|||
}); |
|||
</code></pre> |
|||
|
|||
<h2 id="log-output">Log Output</h2> |
|||
|
|||
<p>Now lets see what log output we get when somebody hits our API's endpoint:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>$ curl -iSs http://0.0.0.0:8080/hello?name=paul |
|||
HTTP/1.1 200 OK |
|||
... |
|||
X-Request-Id: 9496dfdd-4ec7-4b59-aae7-3fed57aed5ba |
|||
... |
|||
|
|||
{"hello":"paul"} |
|||
</code></pre> |
|||
|
|||
<p>Here is the server log:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>[trentm@banana:~/tm/hello-json-logging]$ node server.js |
|||
... intro "listening at" log message elided ... |
|||
{"name":"helloapi","hostname":"banana.local","pid":40341,"level":30,"req":{"method":"GET","url":"/hello?name=paul","headers":{"user-agent":"curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3","host":"0.0.0.0:8080","accept":"*/*"},"remoteAddress":"127.0.0.1","remotePort":59831},"msg":"start","time":"2012-03-28T17:37:29.506Z","v":0} |
|||
{"name":"helloapi","hostname":"banana.local","pid":40341,"route":"SayHello","req_id":"9496dfdd-4ec7-4b59-aae7-3fed57aed5ba","level":20,"msg":"caller is \"paul\"","time":"2012-03-28T17:37:29.507Z","v":0} |
|||
{"name":"helloapi","hostname":"banana.local","pid":40341,"route":"SayHello","req_id":"9496dfdd-4ec7-4b59-aae7-3fed57aed5ba","level":30,"res":{"statusCode":200,"headers":{"access-control-allow-origin":"*","access-control-allow-headers":"Accept, Accept-Version, Content-Length, Content-MD5, Content-Type, Date, X-Api-Version","access-control-expose-headers":"X-Api-Version, X-Request-Id, X-Response-Time","server":"Hello API","x-request-id":"9496dfdd-4ec7-4b59-aae7-3fed57aed5ba","access-control-allow-methods":"GET","connection":"close","content-length":16,"content-md5":"Xmn3QcFXaIaKw9RPUARGBA==","content-type":"application/json","date":"Wed, 28 Mar 2012 17:37:29 GMT","x-response-time":3}},"msg":"finished","time":"2012-03-28T17:37:29.510Z","v":0} |
|||
</code></pre> |
|||
|
|||
<p>Lets look at each in turn to see what is interesting -- pretty-printed with <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">node server.js | ./node_modules/.bin/bunyan -j</code>:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>{ // (1) |
|||
"name": "helloapi", |
|||
"hostname": "banana.local", |
|||
"pid": 40442, |
|||
"level": 30, |
|||
"req": { |
|||
"method": "GET", |
|||
"url": "/hello?name=paul", |
|||
"headers": { |
|||
"user-agent": "curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3", |
|||
"host": "0.0.0.0:8080", |
|||
"accept": "*/*" |
|||
}, |
|||
"remoteAddress": "127.0.0.1", |
|||
"remotePort": 59834 |
|||
}, |
|||
"msg": "start", |
|||
"time": "2012-03-28T17:39:44.880Z", |
|||
"v": 0 |
|||
} |
|||
</code></pre> |
|||
|
|||
<p>Here we logged the incoming request with <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">request.log.info({req: request}, 'start')</code>. The use of the "req" field triggers the <a href="https://github.com/trentm/node-bunyan/blob/master/lib/bunyan.js#L857-870">"req" serializer</a> <a href="https://github.com/trentm/hello-json-logging/blob/master/server.js#L24">registered at Logger creation</a>.</p> |
|||
|
|||
<p>Next the <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">req.log.debug</code> in our handler:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>{ // (2) |
|||
"name": "helloapi", |
|||
"hostname": "banana.local", |
|||
"pid": 40442, |
|||
"route": "SayHello", |
|||
"req_id": "9496dfdd-4ec7-4b59-aae7-3fed57aed5ba", |
|||
"level": 20, |
|||
"msg": "caller is \"paul\"", |
|||
"time": "2012-03-28T17:39:44.883Z", |
|||
"v": 0 |
|||
} |
|||
</code></pre> |
|||
|
|||
<p>and the log of response in the "after" event:</p> |
|||
|
|||
<pre style="overflow:auto;color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:5px;"><code>{ // (3) |
|||
"name": "helloapi", |
|||
"hostname": "banana.local", |
|||
"pid": 40442, |
|||
"route": "SayHello", |
|||
"req_id": "9496dfdd-4ec7-4b59-aae7-3fed57aed5ba", |
|||
"level": 30, |
|||
"res": { |
|||
"statusCode": 200, |
|||
"headers": { |
|||
"access-control-allow-origin": "*", |
|||
"access-control-allow-headers": "Accept, Accept-Version, Content-Length, Content-MD5, Content-Type, Date, X-Api-Version", |
|||
"access-control-expose-headers": "X-Api-Version, X-Request-Id, X-Response-Time", |
|||
"server": "Hello API", |
|||
"x-request-id": "9496dfdd-4ec7-4b59-aae7-3fed57aed5ba", |
|||
"access-control-allow-methods": "GET", |
|||
"connection": "close", |
|||
"content-length": 16, |
|||
"content-md5": "Xmn3QcFXaIaKw9RPUARGBA==", |
|||
"content-type": "application/json", |
|||
"date": "Wed, 28 Mar 2012 17:39:44 GMT", |
|||
"x-response-time": 5 |
|||
} |
|||
}, |
|||
"msg": "finished", |
|||
"time": "2012-03-28T17:39:44.886Z", |
|||
"v": 0 |
|||
} |
|||
</code></pre> |
|||
|
|||
<p>Two useful details of note here:</p> |
|||
|
|||
<ol> |
|||
<li><p>The last two log messages include <strong>a "req_id" field</strong> (added to the <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">req.log</code> logger by restify). Note that this is the same UUID as the "X-Request-Id" header in the <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">curl</code> response. This means that if you use <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">req.log</code> for logging in your API handlers you will get an easy way to collate all logging for particular requests.</p> |
|||
|
|||
<p>If your's is an SOA system with many services, a best practice is to carry that X-Request-Id/req_id through your system to enable collating handling of a single top-level request.</p></li> |
|||
<li><p>The last two log messages include <strong>a "route" field</strong>. This tells you to which handler restify routed the request. While possibly useful for debugging, this can be very helpful for log-based monitoring of endpoints on a server.</p></li> |
|||
</ol> |
|||
|
|||
<p>Recall that we also setup all logging to go the "hello.log" file. This was set at the TRACE level. Restify will log more detail of its operation at the trace level. See <a href="https://gist.github.com/1761772">my "hello.log"</a> for an example. The <code style="color:#999;background-color:#2f2f2f;border:1px solid #484848;padding:.2em .4em;">bunyan</code> tool does a decent job of <a href="https://gist.github.com/1761772#file_2.+cat+hello.log+pipe+bunyan">nicely formatting</a> multiline messages and "req"/"res" keys (with color, not shown in the gist).</p> |
|||
|
|||
<p><em>This</em> is logging you can use effectively.</p> |
|||
|
|||
<h1 style="margin:48px 0 24px;" id="other-tools">Other Tools</h1> |
|||
|
|||
<p>Bunyan is just one of many options for logging in node.js-land. Others (that I know of) supporting JSON logging are <a href="https://github.com/flatiron/winston#readme">winston</a> and <a href="https://github.com/pquerna/node-logmagic/">logmagic</a>. Paul Querna has <a href="http://journal.paul.querna.org/articles/2011/12/26/log-for-machines-in-json/">an excellent post on using JSON for logging</a>, which shows logmagic usage and also touches on topics like the GELF logging format, log transporting, indexing and searching.</p> |
|||
|
|||
<h1 style="margin:48px 0 24px;" id="final-thoughts">Final Thoughts</h1> |
|||
|
|||
<p>Parsing challenges won't ever completely go away, but it can for your logs if you use JSON. Collating log records across logs from multiple nodes is facilitated by a common "time" field. Correlating logging across multiple services is enabled by carrying a common "req_id" (or equivalent) through all such logs.</p> |
|||
|
|||
<p>Separate log files for a single service is an anti-pattern. The typical Apache example of separate access and error logs is legacy, not an example to follow. A JSON log provides the structure necessary for tooling to easily filter for log records of a particular type.</p> |
|||
|
|||
<p>JSON logs bring possibilities. Feeding to tools like Splunk becomes easy. Ad hoc fields allow for a lightly spec'd comm channel from apps to other services: records with a "metric" could feed to <a href="http://codeascraft.etsy.com/2011/02/15/measure-anything-measure-everything/">statsd</a>, records with a "loggly: true" could feed to loggly.com.</p> |
|||
|
|||
<p>Here I've described a very simple example of restify and bunyan usage for node.js-based API services with easy JSON logging. Restify provides a powerful framework for robust API services. Bunyan provides a light API for nice JSON logging and the beginnings of tooling to help consume Bunyan JSON logs.</p> |
|||
|
|||
<p><strong>Update (29-Mar-2012):</strong> Fix styles somewhat for RSS readers.</p> |
|||
@ -1,52 +0,0 @@ |
|||
title: Node.js and the Road Ahead |
|||
date: Thu Jan 16 15:00:00 PST 2014 |
|||
author: Timothy J Fontaine |
|||
slug: nodejs-road-ahead |
|||
|
|||
As the new project lead for Node.js I am excited for our future, and want to |
|||
give you an update on where we are. |
|||
|
|||
One of Node's major goals is to provide a small core, one that provides the |
|||
right amount of surface area for consumers to achieve and innovate, without |
|||
Node itself getting in the way. That ethos is alive and well, we're going to |
|||
continue to provide a small, simple, and stable set of APIs that facilitate the |
|||
amazing uses the community finds for Node. We're going to keep providing |
|||
backward compatible APIs, so code you write today will continue to work on |
|||
future versions of Node. And of course, performance tuning and bug fixing will |
|||
always be an important part of every release cycle. |
|||
|
|||
The release of Node v0.12 is imminent, and a lot of significant work has gone |
|||
into this release. There's streams3, a better keep alive agent for http, the vm |
|||
module is now based on contextify, and significant performance work done in |
|||
core features (Buffers, TLS, streams). We have a few APIs that are still being |
|||
ironed out before we can feature freeze and branch (execSync, AsyncListeners, |
|||
user definable instrumentation). We are definitely in the home stretch. |
|||
|
|||
But Node is far from done. In the short term there will be new releases of v8 |
|||
that we'll need to track, as well as integrating the new ABI stable C module |
|||
interface. There are interesting language features that we can use to extend |
|||
Node APIs (extend not replace). We need to write more tooling, we need to |
|||
expose more interfaces to further enable innovation. We can explore |
|||
functionality to embed Node in your existing project. |
|||
|
|||
The list can go on and on. Yet, Node is larger than the software itself. Node |
|||
is also the community, the businesses, the ecosystems, and their related |
|||
events. With that in mind there are things we can work to improve. |
|||
|
|||
The core team will be improving its procedures such that we can quickly and |
|||
efficiently communicate with you. We want to provide high quality and timely |
|||
responses to issues, describe our development roadmap, as well as provide our |
|||
progress during each release cycle. We know you're interested in our plans for |
|||
Node, and it's important we're able to provide that information. Communication |
|||
should be bidirectional: we want to continue to receive feedback about how |
|||
you're using Node, and what your pain points are. |
|||
|
|||
After the release of v0.12 we will facilitate the community to contribute and |
|||
curate content for nodejs.org. Allowing the community to continue to invest in |
|||
Node will ensure nodejs.org is an excellent starting point and the primary |
|||
resource for tutorials, documentation, and materials regarding Node. We have an |
|||
awesome and engaged community, and they're paramount to our success. |
|||
|
|||
I'm excited for Node's future, to see new and interesting use cases, and to |
|||
continue to help businesses scale and innovate with Node. We have a lot we can |
|||
accomplish together, and I look forward to seeing those results. |
|||
@ -1,82 +0,0 @@ |
|||
date: Tue Nov 26 07:14:59 PST 2013 |
|||
author: Charlie Robbins |
|||
title: Keeping The npm Registry Awesome |
|||
slug: npm-post-mortem |
|||
category: npm |
|||
|
|||
We know the availability and overall health of The npm Registry is paramount to everyone using Node.js as well as the larger JavaScript community and those of your using it for [some][browserify] [awesome][dotc] [projects][npm-rubygems] [and ideas][npm-python]. Between November 4th and November 15th 2013 The npm Registry had several hours of downtime over three distinct time periods: |
|||
|
|||
1. November 4th -- 16:30 to 15:00 UTC |
|||
2. November 13th -- 15:00 to 19:30 UTC |
|||
3. November 15th -- 15:30 to 18:00 UTC |
|||
|
|||
The root cause of these downtime was insufficient resources: both hardware and human. This is a full post-mortem where we will be look at how npmjs.org works, what went wrong, how we changed the previous architecture of The npm Registry to fix it, as well next steps we are taking to prevent this from happening again. |
|||
|
|||
All of the next steps require additional expenditure from Nodejitsu: both servers and labor. This is why along with this post-mortem we are announcing our [crowdfunding campaign: scalenpm.org](https://scalenpm.org)! Our goal is to raise enough funds so that Nodejitsu can continue to run The npm Registry as a free service for _you, the community._ |
|||
|
|||
Please take a minute now to donate at [https://scalenpm.org](https://scalenpm.org)! |
|||
|
|||
## How does npmjs.org work? |
|||
|
|||
There are two distinct components that make up npmjs.org operated by different people: |
|||
|
|||
* **http://registry.npmjs.org**: The main CouchApp (Github: [isaacs/npmjs.org](https://github.com/isaacs/npmjs.org)) that stores both package tarballs and metadata. It is operated by Nodejitsu since we [acquired IrisCouch in May](https://www.nodejitsu.com/company/press/2013/05/22/iriscouch/). The primary system administrator is [Jason Smith](https://github.com/jhs), the current CTO at Nodejitsu, cofounder of IrisCouch, and the System Administrator of registry.npmjs.org since 2011. |
|||
* **http://npmjs.org**: The npmjs website that you interact with using a web browser. It is a Node.js program (Github: [isaacs/npm-www](https://github.com/isaacs/npm-www)) maintained and operated by Isaac and running on a Joyent Public Cloud SmartMachine. |
|||
|
|||
Here is a high-level summary of the _old architecture:_ |
|||
|
|||
<img width=600 src="https://i.cloudup.com/bapm3fk8Ve-3000x3000.png" alt="old npm architecture"> |
|||
<div style="text-align:center"> |
|||
_Diagram 1. Old npm architecture_ |
|||
</div> |
|||
|
|||
## What went wrong and how was it fixed? |
|||
|
|||
As illustrated above, before November 13th, 2013, npm operated as a single CouchDB server with regular daily backups. We briefly ran a multi-master CouchDB setup after downtime back in August, but after reports that `npm login` no longer worked correctly we rolled back to a single CouchDB server. On both November 13th and November 15th CouchDB became unresponsive on requests to the `/registry` database while requests to all other databases (e.g. `/public_users`) remained responsive. Although the root cause of the CouchDB failures have yet to be determined given that only requests to `/registry` were slow and/or timed out we suspect it is related to the massive number of attachments stored in the registry. |
|||
|
|||
The incident on November 4th was ultimately resolved by a reboot and resize of the host machine, but when the same symptoms reoccured less than 10 days later additional steps were taken: |
|||
|
|||
1. The [registry was moved to another machine][ops-new-machine] of equal resources to exclude the possibility of a hardware issue. |
|||
2. The [registry database itself][ops-compaction] was [compacted][compaction]. |
|||
|
|||
When neither of these yielded a solution Jason Smith and I decided to move to a multi-master architecture with continuous replication illustrated below: |
|||
|
|||
<img width=600 src="https://i.cloudup.com/xu1faVCq8p-3000x3000.png" alt="current npm architecture"> |
|||
<div style="text-align:center"> |
|||
_Diagram 2. Current npm architecture -- Red-lines denote continuous replication_ |
|||
</div> |
|||
|
|||
This _should_ have been the end of our story but unfortunately our supervision logic did not function properly to restart the secondary master on the morning of November 15th. During this time we [moved briefly][ops-single-server] back to a single master architecture. Since then the secondary master has been closely monitored by the entire Nodejitsu operations team to ensure it's continued stability. |
|||
|
|||
## What is being done to prevent future incidents? |
|||
|
|||
The public npm registry simply cannot go down. **Ever.** We gained a lot of operational knowledge about The npm Registry and about CouchDB as a result of these outages. This new knowledge has made clear several steps that we need to take to prevent future downtime: |
|||
|
|||
1. **Always be in multi-master**: The multi-master CouchDB architecture we have setup will scale to more than just two CouchDB servers. _As npm grows we'll be able to add additional capacity!_ |
|||
2. **Decouple www.npmjs.org and registry.npmjs.org**: Right now www.npmjs.org still depends directly on registry.npmjs.org. We are planning to add an additional replica to the current npm architecture so that Isaac can more easily service requests to www.npmjs.org. That means it won't go down if the registry goes down. |
|||
3. **Always have a spare replica**: We need have a hot spare replica running continuous replication from either to swap out when necessary. This is also important as we need to regularly run compaction on each master since the registry is growing ~10GB per week on disk. |
|||
4. **Move attachments out of CouchDB**: Work has begun to move the package tarballs out of CouchDB and into [Joyent's Manta service](http://www.joyent.com/products/manta). Additionally, [MaxCDN](http://www.maxcdn.com/) has generously offered to provide CDN services for npm, once the tarballs are moved out of the registry database. This will help improve delivery speed, while dramatically reducing the file system I/O load on the CouchDB servers. Work is progressing slowly, because at each stage in the plan, we are making sure that current replication users are minimally impacted. |
|||
|
|||
When these new infrastructure components are in-place The npm Registry will look like this: |
|||
|
|||
<img width=600 src="https://i.cloudup.com/XwrpFNICJ2-3000x3000.png" alt="planned npm architecture"> |
|||
<div style="text-align:center"> |
|||
_Diagram 3. Planned npm architecture -- Red-lines denote continuous replication_ |
|||
</div> |
|||
|
|||
## You are npm! And we need your help! |
|||
|
|||
The npm Registry has had a 10x year. In November 2012 there were 13.5 million downloads. In October 2013 there were **114.6 million package downloads.** We're honored to have been a part of sustaining this growth for the community and we want to see it continue to grow to a billion package downloads a month and beyond. |
|||
|
|||
_**But we need your help!**_ All of these necessary improvements require more servers, more time from Nodejitsu staff and an overall increase to what we spend maintaining the public npm registry as a free service for the Node.js community. |
|||
|
|||
Please take a minute now to donate at [https://scalenpm.org](https://scalenpm.org)! |
|||
|
|||
[browserify]: http://browserify.org/ |
|||
[dotc]: https://github.com/substack/dotc |
|||
[npm-rubygems]: http://andrew.ghost.io/emulating-node-js-modules-in-ruby/ |
|||
[npm-python]: https://twitter.com/__lucas/status/391688082573258753 |
|||
[ops-new-machine]: https://twitter.com/npmjs/status/400692071377276928 |
|||
[ops-compaction]: https://twitter.com/npmjs/status/400705715846643712 |
|||
[compaction]: http://wiki.apache.org/couchdb/Compaction |
|||
[ops-single-server]: https://twitter.com/npmjs/status/401384681507016704 |
|||
@ -1,167 +0,0 @@ |
|||
title: Managing Node.js Dependencies with Shrinkwrap |
|||
author: Dave Pacheco |
|||
date: Mon Feb 27 2012 10:51:59 GMT-0800 (PST) |
|||
status: publish |
|||
category: npm |
|||
slug: managing-node-js-dependencies-with-shrinkwrap |
|||
|
|||
<p style="float:right;text-align:center;margin:5px;"><a href="http://www.flickr.com/photos/luc_viatour/4247957432/"><img class="size-medium wp-image-652" style="border:1px #000000 solid;" title="Web" src="http://dtrace.org/blogs/dap/files/2012/02/web-300x300.jpg" alt="" width="250" height="250" /></a><br> |
|||
Photo by Luc Viatour (flickr)</p> |
|||
|
|||
<p>Managing dependencies is a fundamental problem in building complex software. The terrific success of github and <a href="http://npmjs.org/">npm</a> have made code reuse especially easy in the Node world, where packages don't exist in isolation but rather as nodes in a large graph. The software is constantly changing (releasing new versions), and each package has its own constraints about what other packages it requires to run (dependencies). npm keeps track of these constraints, and authors express what kind of changes are compatible using <a href="http://npmjs.org/doc/semver.html">semantic versioning</a>, allowing authors to specify that their package will work with even future versions of its dependencies as long as the semantic versions are assigned properly. |
|||
|
|||
</p> |
|||
<p>This does mean that when you "npm install" a package with dependencies, there's no guarantee that you'll get the same set of code now that you would have gotten an hour ago, or that you would get if you were to run it again an hour later. You may get a bunch of bug fixes now that weren't available an hour ago. This is great during development, where you want to keep up with changes upstream. It's not necessarily what you want for deployment, though, where you want to validate whatever bits you're actually shipping. |
|||
|
|||
</p> |
|||
<p>Put differently, <strong>it's understood that all software changes incur some risk, and it's critical to be able to manage this risk on your own terms</strong>. Taking that risk in development is good because by definition that's when you're incorporating and testing software changes. On the other hand, if you're shipping production software, you probably don't want to take this risk when cutting a release candidate (i.e. build time) or when you actually ship (i.e. deploy time) because you want to validate whatever you ship. |
|||
|
|||
</p> |
|||
<p>You can address a simple case of this problem by only depending on specific versions of packages, allowing no semver flexibility at all, but this falls apart when you depend on packages that don't also adopt the same principle. Many of us at Joyent started wondering: can we generalize this approach? |
|||
|
|||
</p> |
|||
<h2>Shrinkwrapping packages</h2> |
|||
<p>That brings us to <a href="http://npmjs.org/doc/shrinkwrap.html">npm shrinkwrap</a><a href="#note1-note" name="note1-top">[1]</a>: |
|||
|
|||
</p> |
|||
<pre><code>NAME |
|||
npm-shrinkwrap -- Lock down dependency versions |
|||
|
|||
SYNOPSIS |
|||
npm shrinkwrap |
|||
|
|||
DESCRIPTION |
|||
This command locks down the versions of a package's dependencies so |
|||
that you can control exactly which versions of each dependency will |
|||
be used when your package is installed.</code></pre> |
|||
<p>Let's consider package A: |
|||
|
|||
</p> |
|||
<pre><code>{ |
|||
"name": "A", |
|||
"version": "0.1.0", |
|||
"dependencies": { |
|||
"B": "<0.1.0" |
|||
} |
|||
}</code></pre> |
|||
<p>package B: |
|||
|
|||
</p> |
|||
<pre><code>{ |
|||
"name": "B", |
|||
"version": "0.0.1", |
|||
"dependencies": { |
|||
"C": "<0.1.0" |
|||
} |
|||
}</code></pre> |
|||
<p>and package C: |
|||
|
|||
</p> |
|||
<pre><code>{ |
|||
"name": "C, |
|||
"version": "0.0.1" |
|||
}</code></pre> |
|||
<p>If these are the only versions of A, B, and C available in the registry, then a normal "npm install A" will install: |
|||
|
|||
</p> |
|||
<pre><code>A@0.1.0 |
|||
└─┬ B@0.0.1 |
|||
└── C@0.0.1</code></pre> |
|||
<p>Then if B@0.0.2 is published, then a fresh "npm install A" will install: |
|||
|
|||
</p> |
|||
<pre><code>A@0.1.0 |
|||
└─┬ B@0.0.2 |
|||
└── C@0.0.1</code></pre> |
|||
<p>assuming the new version did not modify B's dependencies. Of course, the new version of B could include a new version of C and any number of new dependencies. As we said before, if A's author doesn't want that, she could specify a dependency on B@0.0.1. But if A's author and B's author are not the same person, there's no way for A's author to say that she does not want to pull in newly published versions of C when B hasn't changed at all. |
|||
|
|||
</p> |
|||
<p>In this case, A's author can use |
|||
|
|||
</p> |
|||
<pre><code># npm shrinkwrap</code></pre> |
|||
<p>This generates npm-shrinkwrap.json, which will look something like this: |
|||
|
|||
</p> |
|||
<pre><code>{ |
|||
"name": "A", |
|||
"dependencies": { |
|||
"B": { |
|||
"version": "0.0.1", |
|||
"dependencies": { |
|||
"C": { "version": "0.1.0" } |
|||
} |
|||
} |
|||
} |
|||
}</code></pre> |
|||
<p>The shrinkwrap command has locked down the dependencies based on what's currently installed in node_modules. <strong>When "npm install" installs a package with a npm-shrinkwrap.json file in the package root, the shrinkwrap file (rather than package.json files) completely drives the installation of that package and all of its dependencies (recursively).</strong> So now the author publishes A@0.1.0, and subsequent installs of this package will use B@0.0.1 and C@0.1.0, regardless the dependencies and versions listed in A's, B's, and C's package.json files. If the authors of B and C publish new versions, they won't be used to install A because the shrinkwrap refers to older versions. Even if you generate a new shrinkwrap, it will still reference the older versions, since "npm shrinkwrap" uses what's installed locally rather than what's available in the registry. |
|||
|
|||
</p> |
|||
<h4>Using shrinkwrapped packages</h4> |
|||
<p>Using a shrinkwrapped package is no different than using any other package: you can "npm install" it by hand, or add a dependency to your package.json file and "npm install" it. |
|||
|
|||
</p> |
|||
<h4>Building shrinkwrapped packages</h4> |
|||
<p>To shrinkwrap an existing package: |
|||
|
|||
</p> |
|||
<ol> |
|||
<li>Run "npm install" in the package root to install the current versions of all dependencies.</li> |
|||
<li>Validate that the package works as expected with these versions.</li> |
|||
<li>Run "npm shrinkwrap", add npm-shrinkwrap.json to git, and publish your package.</li> |
|||
</ol> |
|||
<p>To add or update a dependency in a shrinkwrapped package: |
|||
|
|||
</p> |
|||
<ol> |
|||
<li>Run "npm install" in the package root to install the current versions of all dependencies.</li> |
|||
<li>Add or update dependencies. "npm install" each new or updated package individually and then update package.json.</li> |
|||
<li>Validate that the package works as expected with the new dependencies.</li> |
|||
<li>Run "npm shrinkwrap", commit the new npm-shrinkwrap.json, and publish your package.</li> |
|||
</ol> |
|||
<p>You can still use <a href="http://npmjs.org/doc/outdated.html">npm outdated(1)</a> to view which dependencies have newer versions available. |
|||
|
|||
</p> |
|||
<p>For more details, check out the full docs on <a href="http://npmjs.org/doc/shrinkwrap.html">npm shrinkwrap</a>, from which much of the above is taken. |
|||
|
|||
</p> |
|||
<h2>Why not just check <code>node_modules</code> into git?</h2> |
|||
<p>One previously <a href="http://www.mikealrogers.com/posts/nodemodules-in-git.html">proposed solution</a> is to "npm install" your dependencies during development and commit the results into source control. Then you deploy your app from a specific git SHA knowing you've got exactly the same bits that you tested in development. This does address the problem, but it has its own issues: for one, binaries are tricky because you need to "npm install" them to get their sources, but this builds the [system-dependent] binary too. You can avoid checking in the binaries and use "npm rebuild" at build time, but we've had a lot of difficulty trying to do this.<a href="#note2-note" name="note2-top">[2]</a> At best, this is second-class treatment for binary modules, which are critical for many important types of Node applications.<a href="#note3-note" name="note3-top">[3]</a> |
|||
|
|||
</p> |
|||
<p>Besides the issues with binary modules, this approach just felt wrong to many of us. There's a reason we don't check binaries into source control, and it's not just because they're platform-dependent. (After all, we could build and check in binaries for all supported platforms and operating systems.) It's because that approach is error-prone and redundant: error-prone because it introduces a new human failure mode where someone checks in a source change but doesn't regenerate all the binaries, and redundant because the binaries can always be built from the sources alone. An important principle of software version control is that you don't check in files derived directly from other files by a simple transformation.<a href="#note4-note" name="note4-top">[4]</a> Instead, you check in the original sources and automate the transformations via the build process. |
|||
|
|||
</p> |
|||
<p>Dependencies are just like binaries in this regard: they're files derived from a simple transformation of something else that is (or could easily be) already available: the name and version of the dependency. Checking them in has all the same problems as checking in binaries: people could update package.json without updating the checked-in module (or vice versa). Besides that, adding new dependencies has to be done by hand, introducing more opportunities for error (checking in the wrong files, not checking in certain files, inadvertently changing files, and so on). Our feeling was: why check in this whole dependency tree (and create a mess for binary add-ons) when we could just check in the package name and version and have the build process do the rest? |
|||
|
|||
</p> |
|||
<p>Finally, the approach of checking in node_modules doesn't really scale for us. We've got at least a dozen repos that will use restify, and it doesn't make sense to check that in everywhere when we could instead just specify which version each one is using. There's another principle at work here, which is <strong>separation of concerns</strong>: each repo specifies <em>what</em> it needs, while the build process figures out <em>where to get it</em>. |
|||
|
|||
</p> |
|||
<h2>What if an author republishes an existing version of a package?</h2> |
|||
<p>We're not suggesting deploying a shrinkwrapped package directly and running "npm install" to install from shrinkwrap in production. We already have a build process to deal with binary modules and other automateable tasks. That's where we do the "npm install". We tar up the result and distribute the tarball. Since we test each build before shipping, we won't deploy something we didn't test. |
|||
|
|||
</p> |
|||
<p>It's still possible to pick up newly published versions of existing packages at build time. We assume force publish is not that common in the first place, let alone force publish that breaks compatibility. If you're worried about this, you can use git SHAs in the shrinkwrap or even consider maintaining a mirror of the part of the npm registry that you use and require human confirmation before mirroring unpublishes. |
|||
|
|||
</p> |
|||
<h2>Final thoughts</h2> |
|||
<p>Of course, the details of each use case matter a lot, and the world doesn't have to pick just one solution. If you like checking in node_modules, you should keep doing that. We've chosen the shrinkwrap route because that works better for us. |
|||
|
|||
</p> |
|||
<p>It's not exactly news that Joyent is heavy on Node. Node is the heart of our SmartDataCenter (SDC) product, whose public-facing web portal, public API, Cloud Analytics, provisioning, billing, heartbeating, and other services are all implemented in Node. That's why it's so important to us to have robust components (like <a href="https://github.com/trentm/node-bunyan">logging</a> and <a href="http://mcavage.github.com/node-restify/">REST</a>) and tools for <a href="http://dtrace.org/blogs/dap/2012/01/13/playing-with-nodev8-postmortem-debugging/">understanding production failures postmortem</a>, <a href="http://dtrace.org/blogs/dap/2012/01/05/where-does-your-node-program-spend-its-time/">profile Node apps in production</a>, and now managing Node dependencies. Again, we're interested to hear feedback from others using these tools. |
|||
|
|||
</p> |
|||
<hr /> |
|||
Dave Pacheco blogs at <a href="http://dtrace.org/blogs/dap/">dtrace.org</a>. |
|||
|
|||
<p><a href="#note1-top" name="note1-note">[1]</a> Much of this section is taken directly from the "npm shrinkwrap" documentation. |
|||
|
|||
</p> |
|||
<p><a href="#note2-top" name="note2-note">[2]</a> We've had a lot of trouble with checking in node_modules with binary dependencies. The first problem is figuring out exactly which files <em>not</em> to check in (<em>.o, </em>.node, <em>.dynlib, </em>.so, *.a, ...). When <a href="https://twitter.com/#!/mcavage">Mark</a> went to apply this to one of our internal services, the "npm rebuild" step blew away half of the dependency tree because it ran "make clean", which in dependency <a href="http://ldapjs.org/">ldapjs</a> brings the repo to a clean slate by blowing away its dependencies. Later, a new (but highly experienced) engineer on our team was tasked with fixing a bug in our Node-based DHCP server. To fix the bug, we went with a new dependency. He tried checking in node_modules, which added 190,000 lines of code (to this repo that was previously a few hundred LOC). And despite doing everything he could think of to do this correctly and test it properly, the change broke the build because of the binary modules. So having tried this approach a few times now, it appears quite difficult to get right, and as I pointed out above, the lack of actual documentation and real world examples suggests others either aren't using binary modules (which we know isn't true) or haven't had much better luck with this approach. |
|||
|
|||
</p> |
|||
<p><a href="#note3-top" name="note3-note">[3]</a> Like a good Node-based distributed system, our architecture uses lots of small HTTP servers. Each of these serves a REST API using <a href="http://mcavage.github.com/node-restify/">restify</a>. restify uses the binary module <a href="https://github.com/chrisa/node-dtrace-provider">node-dtrace-provider</a>, which gives each of our services <a href="http://mcavage.github.com/node-restify/#DTrace">deep DTrace-based observability for free</a>. So literally almost all of our components are or will soon be depending on a binary add-on. Additionally, the foundation of <a href="http://dtrace.org/blogs/dap/2011/03/01/welcome-to-cloud-analytics/">Cloud Analytics</a> are a pair of binary modules that extract data from <a href="https://github.com/bcantrill/node-libdtrace">DTrace</a> and <a href="https://github.com/bcantrill/node-kstat">kstat</a>. So this isn't a corner case for us, and we don't believe we're exceptional in this regard. The popular <a href="https://github.com/pietern/hiredis-node">hiredis</a> package for interfacing with redis from Node is also a binary module. |
|||
|
|||
</p> |
|||
<p><a href="#note4-top" name="note4-note">[4]</a> Note that I said this is an important principle for <em>software version control</em>, not using git in general. People use git for lots of things where checking in binaries and other derived files is probably fine. Also, I'm not interested in proselytizing; if you want to do this for software version control too, go ahead. But don't do it out of ignorance of existing successful software engineering practices.</p> |
|||
@ -1,64 +0,0 @@ |
|||
title: npm 1.0: Global vs Local installation |
|||
author: Isaac Schlueter |
|||
date: Wed Mar 23 2011 23:07:13 GMT-0700 (PDT) |
|||
status: publish |
|||
category: npm |
|||
slug: npm-1-0-global-vs-local-installation |
|||
|
|||
<p><i>npm 1.0 is in release candidate mode. <a href="http://groups.google.com/group/npm-/browse_thread/thread/43d3e76d71d1f141">Go get it!</a></i></p> |
|||
|
|||
<p>More than anything else, the driving force behind the npm 1.0 rearchitecture was the desire to simplify what a package installation directory structure looks like.</p> |
|||
|
|||
<p>In npm 0.x, there was a command called <code>bundle</code> that a lot of people liked. <code>bundle</code> let you install your dependencies locally in your project, but even still, it was basically a hack that never really worked very reliably.</p> |
|||
|
|||
<p>Also, there was that activation/deactivation thing. That’s confusing.</p> |
|||
|
|||
<h2>Two paths</h2> |
|||
|
|||
<p>In npm 1.0, there are two ways to install things:</p> |
|||
|
|||
<ol> <li>globally —- This drops modules in <code>{prefix}/lib/node_modules</code>, and puts executable files in <code>{prefix}/bin</code>, where <code>{prefix}</code> is usually something like <code>/usr/local</code>. It also installs man pages in <code>{prefix}/share/man</code>, if they’re supplied.</li> <li>locally —- This installs your package in the current working directory. Node modules go in <code>./node_modules</code>, executables go in <code>./node_modules/.bin/</code>, and man pages aren’t installed at all.</li> </ol> |
|||
|
|||
<h2>Which to choose</h2> |
|||
|
|||
<p>Whether to install a package globally or locally depends on the <code>global</code> config, which is aliased to the <code>-g</code> command line switch.</p> |
|||
|
|||
<p>Just like how global variables are kind of gross, but also necessary in some cases, global packages are important, but best avoided if not needed.</p> |
|||
|
|||
<p>In general, the rule of thumb is:</p> |
|||
|
|||
<ol> <li>If you’re installing something that you want to use <em>in</em> your program, using <code>require('whatever')</code>, then install it locally, at the root of your project.</li> <li>If you’re installing something that you want to use in your <em>shell</em>, on the command line or something, install it globally, so that its binaries end up in your <code>PATH</code> environment variable.</li> </ol> |
|||
|
|||
<h2>When you can't choose</h2> |
|||
|
|||
<p>Of course, there are some cases where you want to do both. <a href="http://coffeescript.org/">Coffee-script</a> and <a href="http://expressjs.com/">Express</a> both are good examples of apps that have a command line interface, as well as a library. In those cases, you can do one of the following:</p> |
|||
|
|||
<ol> <li>Install it in both places. Seriously, are you that short on disk space? It’s fine, really. They’re tiny JavaScript programs.</li> <li>Install it globally, and then <code>npm link coffee-script</code> or <code>npm link express</code> (if you’re on a platform that supports symbolic links.) Then you only need to update the global copy to update all the symlinks as well.</li> </ol> |
|||
|
|||
<p>The first option is the best in my opinion. Simple, clear, explicit. The second is really handy if you are going to re-use the same library in a bunch of different projects. (More on <code>npm link</code> in a future installment.)</p> |
|||
|
|||
<p>You can probably think of other ways to do it by messing with environment variables. But I don’t recommend those ways. Go with the grain.</p> |
|||
|
|||
<h2 id="slight_exception_it8217s_not_always_the_cwd">Slight exception: It’s not always the cwd.</h2> |
|||
|
|||
<p>Let’s say you do something like this:</p> |
|||
|
|||
<pre style="background:#333!important;color:#ccc!important;overflow:auto!important;padding:2px!important;"><code>cd ~/projects/foo # go into my project |
|||
npm install express # ./node_modules/express |
|||
cd lib/utils # move around in there |
|||
vim some-thing.js # edit some stuff, work work work |
|||
npm install redis # ./lib/utils/node_modules/redis!? ew.</code></pre> |
|||
|
|||
<p>In this case, npm will install <code>redis</code> into <code>~/projects/foo/node_modules/redis</code>. Sort of like how git will work anywhere within a git repository, npm will work anywhere within a package, defined by having a <code>node_modules</code> folder.</p> |
|||
|
|||
<h2>Test runners and stuff</h2> |
|||
|
|||
<p>If your package's <code>scripts.test</code> command uses a command-line program installed by one of your dependencies, not to worry. npm makes <code>./node_modules/.bin</code> the first entry in the <code>PATH</code> environment variable when running any lifecycle scripts, so this will work fine, even if your program is not globally installed: |
|||
|
|||
<pre style="background:#333!important;color:#ccc!important;overflow:auto!important;padding:2px!important;"><code>{ "name" : "my-program" |
|||
, "version" : "1.2.3" |
|||
, "dependencies": { "express": "*", "coffee-script": "*" } |
|||
, "devDependencies": { "vows": "*" } |
|||
, "scripts": |
|||
{ "test": "vows test/*.js" |
|||
, "preinstall": "cake build" } }</code></pre> |
|||
@ -1,114 +0,0 @@ |
|||
title: npm 1.0: link |
|||
author: Isaac Schlueter |
|||
date: Wed Apr 06 2011 17:40:33 GMT-0700 (PDT) |
|||
status: publish |
|||
category: npm |
|||
slug: npm-1-0-link |
|||
|
|||
<p><i>npm 1.0 is in release candidate mode. <a href="http://groups.google.com/group/npm-/browse_thread/thread/43d3e76d71d1f141">Go get it!</a></i></p> |
|||
|
|||
<p>In npm 0.x, there was a command called <code>link</code>. With it, you could “link-install” a package so that changes would be reflected in real-time. This is especially handy when you’re actually building something. You could make a few changes, run the command again, and voila, your new code would be run without having to re-install every time.</p> |
|||
|
|||
<p>Of course, compiled modules still have to be rebuilt. That’s not ideal, but it’s a problem that will take more powerful magic to solve.</p> |
|||
|
|||
<p>In npm 0.x, this was a pretty awful kludge. Back then, every package existed in some folder like:</p> |
|||
|
|||
<pre><code>prefix/lib/node/.npm/my-package/1.3.6/package |
|||
</code></pre> |
|||
|
|||
<p>and the package’s version and name could be inferred from the path. Then, symbolic links were set up that looked like:</p> |
|||
|
|||
<pre><code>prefix/lib/node/my-package@1.3.6 -> ./.npm/my-package/1.3.6/package |
|||
</code></pre> |
|||
|
|||
<p>It was easy enough to point that symlink to a different location. However, since the <em>package.json file could change</em>, that meant that the connection between the version and the folder was not reliable.</p> |
|||
|
|||
<p>At first, this was just sort of something that we dealt with by saying, “Relink if you change the version.” However, as more and more edge cases arose, eventually the solution was to give link packages this fakey version of “9999.0.0-LINK-hash” so that npm knew it was an impostor. Sometimes the package was treated as if it had the 9999.0.0 version, and other times it was treated as if it had the version specified in the package.json.</p> |
|||
|
|||
<h2 id="a_better_way">A better way</h2> |
|||
|
|||
<p>For npm 1.0, we backed up and looked at what the actual use cases were. Most of the time when you link something you want one of the following:</p> |
|||
|
|||
<ol> |
|||
<li>globally install this package I’m working on so that I can run the command it creates and test its stuff as I work on it.</li> |
|||
<li>locally install my thing into some <em>other</em> thing that depends on it, so that the other thing can <code>require()</code> it.</li> |
|||
</ol> |
|||
|
|||
<p>And, in both cases, changes should be immediately apparent and not require any re-linking.</p> |
|||
|
|||
<p><em>Also</em>, there’s a third use case that I didn’t really appreciate until I started writing more programs that had more dependencies:</p> |
|||
|
|||
<ol start="3"> <li><p>Globally install something, and use it in development in a bunch of projects, and then update them all at once so that they all use the latest version. </ol> |
|||
|
|||
<p>Really, the second case above is a special-case of this third case.</p> |
|||
|
|||
<h2 id="link_devel_global">Link devel → global</h2> |
|||
|
|||
<p>The first step is to link your local project into the global install space. (See <a href="http://blog.nodejs.org/2011/03/23/npm-1-0-global-vs-local-installation/">global vs local installation</a> for more on this global/local business.)</p> |
|||
|
|||
<p>I do this as I’m developing node projects (including npm itself).</p> |
|||
|
|||
<pre><code>cd ~/dev/js/node-tap # go into the project dir |
|||
npm link # create symlinks into {prefix} |
|||
</code></pre> |
|||
|
|||
<p>Because of how I have my computer set up, with <code>/usr/local</code> as my install prefix, I end up with a symlink from <code>/usr/local/lib/node_modules/tap</code> pointing to <code>~/dev/js/node-tap</code>, and the executable linked to <code>/usr/local/bin/tap</code>.</p> |
|||
|
|||
<p>Of course, if you <a href="http://blog.nodejs.org/2011/04/04/development-environment/">set your paths differently</a>, then you’ll have different results. (That’s why I tend to talk in terms of <code>prefix</code> rather than <code>/usr/local</code>.)</p> |
|||
|
|||
<h2 id="link_global_local">Link global → local</h2> |
|||
|
|||
<p>When you want to link the globally-installed package into your local development folder, you run <code>npm link pkg</code> where <code>pkg</code> is the name of the package that you want to install.</p> |
|||
|
|||
<p>For example, let’s say that I wanted to write some tap tests for my node-glob package. I’d <em>first</em> do the steps above to link tap into the global install space, and <em>then</em> I’d do this:</p> |
|||
|
|||
<pre><code>cd ~/dev/js/node-glob # go to the project that uses the thing. |
|||
npm link tap # link the global thing into my project. |
|||
</code></pre> |
|||
|
|||
<p>Now when I make changes in <code>~/dev/js/node-tap</code>, they’ll be immediately reflected in <code>~/dev/js/node-glob/node_modules/tap</code>.</p> |
|||
|
|||
<h2 id="link_to_stuff_you_don8217t_build">Link to stuff you <em>don’t</em> build</h2> |
|||
|
|||
<p>Let’s say I have 15 sites that all use express. I want the benefits of local development, but I also want to be able to update all my dev folders at once. You can globally install express, and then link it into your local development folder.</p> |
|||
|
|||
<pre><code>npm install express -g # install express globally |
|||
cd ~/dev/js/my-blog # development folder one |
|||
npm link express # link the global express into ./node_modules |
|||
cd ~/dev/js/photo-site # other project folder |
|||
npm link express # link express into here, as well |
|||
|
|||
# time passes |
|||
# TJ releases some new stuff. |
|||
# you want this new stuff. |
|||
|
|||
npm update express -g # update the global install. |
|||
# this also updates my project folders. |
|||
</code></pre> |
|||
|
|||
<h2 id="caveat_not_for_real_servers">Caveat: Not For Real Servers</h2> |
|||
|
|||
<p>npm link is a development tool. It’s <em>awesome</em> for managing packages on your local development box. But deploying with npm link is basically asking for problems, since it makes it super easy to update things without realizing it.</p> |
|||
|
|||
<h2 id="caveat_2_sorry_windows">Caveat 2: Sorry, Windows!</h2> |
|||
|
|||
<p>I highly doubt that a native Windows node will ever have comparable symbolic link support to what Unix systems provide. I know that there are junctions and such, and I've heard legends about symbolic links on Windows 7.</p> |
|||
|
|||
<p>When there is a native windows port of Node, if that native windows port has `fs.symlink` and `fs.readlink` support that is exactly identical to the way that they work on Unix, then this should work fine.</p> |
|||
|
|||
<p>But I wouldn't hold my breath. Any bugs about this not working on a native Windows system (ie, not Cygwin) will most likely be closed with <code>wontfix</code>.</p> |
|||
|
|||
|
|||
<h2 id="aside_credit_where_credit8217s_due">Aside: Credit where Credit’s Due</h2> |
|||
|
|||
<p>Back before the Great Package Management Wars of Node 0.1, before npm or kiwi or mode or seed.js could do much of anything, and certainly before any of them had more than 2 users, Mikeal Rogers invited me to the Couch.io offices for lunch to talk about this npm registry thingie I’d mentioned wanting to build. (That is, to convince me to use CouchDB for it.)</p> |
|||
|
|||
<p>Since he was volunteering to build the first version of it, and since couch is pretty much the ideal candidate for this use-case, it was an easy sell.</p> |
|||
|
|||
<p>While I was there, he said, “Look. You need to be able to link a project directory as if it was installed as a package, and then have it all Just Work. Can you do that?”</p> |
|||
|
|||
<p>I was like, “Well, I don’t know… I mean, there’s these edge cases, and it doesn’t really fit with the existing folder structure very well…”</p> |
|||
|
|||
<p>“Dude. Either you do it, or I’m going to have to do it, and then there’ll be <em>another</em> package manager in node, instead of writing a registry for npm, and it won’t be as good anyway. Don’t be python.”</p> |
|||
|
|||
<p>The rest is history.</p> |
|||
@ -1,36 +0,0 @@ |
|||
title: npm 1.0: Released |
|||
author: Isaac Schlueter |
|||
date: Sun May 01 2011 08:09:45 GMT-0700 (PDT) |
|||
status: publish |
|||
category: npm |
|||
slug: npm-1-0-released |
|||
|
|||
<p>npm 1.0 has been released. Here are the highlights:</p> |
|||
|
|||
<ul> <li><a href="http://blog.nodejs.org/2011/03/23/npm-1-0-global-vs-local-installation/">Global vs local installation</a></li> <li><a href="http://blog.nodejs.org/2011/03/17/npm-1-0-the-new-ls/">ls displays a tree</a>, instead of being a remote search</li> <li>No more “activation” concept - dependencies are nested</li> <li><a href="http://blog.nodejs.org/2011/04/06/npm-1-0-link/">Updates to link command</a></li> <li>Install script cleans up any 0.x cruft it finds. (That is, it removes old packages, so that they can be installed properly.)</li> <li>Simplified “search” command. One line per package, rather than one line per version.</li> <li>Renovated “completion” approach</li> <li>More help topics</li> <li>Simplified folder structure</li> </ul> |
|||
|
|||
<p>The focus is on npm being a development tool, rather than an apt-wannabe.</p> |
|||
|
|||
<h2 id="installing_it">Installing it</h2> |
|||
|
|||
<p>To get the new version, run this command:</p> |
|||
|
|||
<pre style="background:#333;color:#ccc;overflow:auto;padding:2px;"><code>curl http://npmjs.org/install.sh | sh </code></pre> |
|||
|
|||
<p>This will prompt to ask you if it’s ok to remove all the old 0.x cruft. If you want to not be asked, then do this:</p> |
|||
|
|||
<pre style="background:#333;color:#ccc;overflow:auto;padding:2px;"><code>curl http://npmjs.org/install.sh | clean=yes sh </code></pre> |
|||
|
|||
<p>Or, if you want to not do the cleanup, and leave the old stuff behind, then do this:</p> |
|||
|
|||
<pre style="background:#333;color:#ccc;overflow:auto;padding:2px;"><code>curl http://npmjs.org/install.sh | clean=no sh </code></pre> |
|||
|
|||
<p>A lot of people in the node community were brave testers and helped make this release a lot better (and swifter) than it would have otherwise been. Thanks :)</p> |
|||
|
|||
<h2 id="code_freeze">Code Freeze</h2> |
|||
|
|||
<p>npm will not have any major feature enhancements or architectural changes <span style="border-bottom:1px dotted;cursor:default;" title="That is, the freeze ends no sooner than November 1, 2011">for at least 6 months</span>. There are interesting developments planned that leverage npm in some ways, but it’s time to let the client itself settle. Also, I want to focus attention on some other problems for a little while.</p> |
|||
|
|||
<p>Of course, <a href="https://github.com/isaacs/npm/issues">bug reports</a> are always welcome.</p> |
|||
|
|||
<p>See you at NodeConf!</p> |
|||
@ -1,144 +0,0 @@ |
|||
title: npm 1.0: The New "ls" |
|||
author: Isaac Schlueter |
|||
date: Thu Mar 17 2011 23:22:17 GMT-0700 (PDT) |
|||
status: publish |
|||
category: npm |
|||
slug: npm-1-0-the-new-ls |
|||
|
|||
<p><em>This is the first in a series of hopefully more than 1 posts, each detailing some aspect of npm 1.0.</em></p> |
|||
|
|||
<p>In npm 0.x, the <code>ls</code> command was a combination of both searching the registry as well as reporting on what you have installed.</p> |
|||
|
|||
<p>As the registry has grown in size, this has gotten unwieldy. Also, since npm 1.0 manages dependencies differently, nesting them in <code>node_modules</code> folder and installing locally by default, there are different things that you want to view.</p> |
|||
|
|||
<p>The functionality of the <code>ls</code> command was split into two different parts. <code>search</code> is now the way to find things on the registry (and it only reports one line per package, instead of one line per version), and <code>ls</code> shows a tree view of the packages that are installed locally.</p> |
|||
|
|||
<p>Here’s an example of the output:</p> |
|||
|
|||
<pre style="background:#333;color:#ccc;overflow:auto;padding:2px;"><code>$ npm ls |
|||
npm@1.0.0 /Users/isaacs/dev-src/js/npm |
|||
├── semver@1.0.1 |
|||
├─┬ ronn@0.3.5 |
|||
│ └── opts@1.2.1 |
|||
└─┬ express@2.0.0rc3 <span style="background:#000;color:#0f0;">extraneous</span> |
|||
├─┬ connect@1.1.0 |
|||
│ ├── qs@0.0.7 |
|||
│ └── mime@1.2.1 |
|||
├── mime@1.2.1 |
|||
└── qs@0.0.7 |
|||
</code></pre> |
|||
|
|||
<p>This is after I’ve done <code>npm install semver ronn express</code> in the npm source directory. Since express isn’t actually a dependency of npm, it shows up with that “extraneous” marker.</p> |
|||
|
|||
<p>Let’s see what happens when we create a broken situation:</p> |
|||
|
|||
<pre style="background:#333;color:#ccc;overflow:auto;padding:2px;"><code>$ rm -rf ./node_modules/express/node_modules/connect |
|||
$ npm ls |
|||
npm@1.0.0 /Users/isaacs/dev-src/js/npm |
|||
├── semver@1.0.1 |
|||
├─┬ ronn@0.3.5 |
|||
│ └── opts@1.2.1 |
|||
└─┬ express@2.0.0rc3 <span style="background:#000;color:#0f0;">extraneous</span> |
|||
├── <span style="background:#000;color:#f00;">UNMET DEPENDENCY</span> connect >= 1.1.0 < 2.0.0 |
|||
├── mime@1.2.1 |
|||
└── qs@0.0.7 |
|||
</code></pre> |
|||
|
|||
<p>Tree views are great for human readability, but some times you want to pipe that stuff to another program. For that output, I took the same datastructure, but instead of building up a treeview string for each line, it spits out just the folders like this:</p> |
|||
|
|||
<pre style="background:#333;color:#ccc;overflow:auto;padding:2px;"><code>$ npm ls -p |
|||
/Users/isaacs/dev-src/js/npm |
|||
/Users/isaacs/dev-src/js/npm/node_modules/semver |
|||
/Users/isaacs/dev-src/js/npm/node_modules/ronn |
|||
/Users/isaacs/dev-src/js/npm/node_modules/ronn/node_modules/opts |
|||
/Users/isaacs/dev-src/js/npm/node_modules/express |
|||
/Users/isaacs/dev-src/js/npm/node_modules/express/node_modules/connect |
|||
/Users/isaacs/dev-src/js/npm/node_modules/express/node_modules/connect/node_modules/qs |
|||
/Users/isaacs/dev-src/js/npm/node_modules/express/node_modules/connect/node_modules/mime |
|||
/Users/isaacs/dev-src/js/npm/node_modules/express/node_modules/mime |
|||
/Users/isaacs/dev-src/js/npm/node_modules/express/node_modules/qs |
|||
</code></pre> |
|||
|
|||
<p>Since you sometimes want a bigger view, I added the <code>--long</code> option to (shorthand: <code>-l</code>) to spit out more info:</p> |
|||
|
|||
<pre style="background:#333;color:#ccc;overflow:auto;padding:2px;"><code>$ npm ls -l |
|||
npm@1.0.0 |
|||
│ /Users/isaacs/dev-src/js/npm |
|||
│ A package manager for node |
|||
│ git://github.com/isaacs/npm.git |
|||
│ http://npmjs.org/ |
|||
├── semver@1.0.1 |
|||
│ ./node_modules/semver |
|||
│ The semantic version parser used by npm. |
|||
│ git://github.com/isaacs/node-semver.git |
|||
├─┬ ronn@0.3.5 |
|||
│ │ ./node_modules/ronn |
|||
│ │ markdown to roff and html converter |
|||
│ └── opts@1.2.1 |
|||
│ ./node_modules/ronn/node_modules/opts |
|||
│ Command line argument parser written in the style of commonjs. To be used with node.js |
|||
└─┬ express@2.0.0rc3 <span style="background:#000;color:#0f0;">extraneous</span> |
|||
│ ./node_modules/express |
|||
│ Sinatra inspired web development framework |
|||
├─┬ connect@1.1.0 |
|||
│ │ ./node_modules/express/node_modules/connect |
|||
│ │ High performance middleware framework |
|||
│ │ git://github.com/senchalabs/connect.git |
|||
│ ├── qs@0.0.7 |
|||
│ │ ./node_modules/express/node_modules/connect/node_modules/qs |
|||
│ │ querystring parser |
|||
│ └── mime@1.2.1 |
|||
│ ./node_modules/express/node_modules/connect/node_modules/mime |
|||
│ A comprehensive library for mime-type mapping |
|||
├── mime@1.2.1 |
|||
│ ./node_modules/express/node_modules/mime |
|||
│ A comprehensive library for mime-type mapping |
|||
└── qs@0.0.7 |
|||
./node_modules/express/node_modules/qs |
|||
querystring parser |
|||
|
|||
$ npm ls -lp |
|||
/Users/isaacs/dev-src/js/npm:npm@1.0.0:::: |
|||
/Users/isaacs/dev-src/js/npm/node_modules/semver:semver@1.0.1:::: |
|||
/Users/isaacs/dev-src/js/npm/node_modules/ronn:ronn@0.3.5:::: |
|||
/Users/isaacs/dev-src/js/npm/node_modules/ronn/node_modules/opts:opts@1.2.1:::: |
|||
/Users/isaacs/dev-src/js/npm/node_modules/express:express@2.0.0rc3:EXTRANEOUS::: |
|||
/Users/isaacs/dev-src/js/npm/node_modules/express/node_modules/connect:connect@1.1.0:::: |
|||
/Users/isaacs/dev-src/js/npm/node_modules/express/node_modules/connect/node_modules/qs:qs@0.0.7:::: |
|||
/Users/isaacs/dev-src/js/npm/node_modules/express/node_modules/connect/node_modules/mime:mime@1.2.1:::: |
|||
/Users/isaacs/dev-src/js/npm/node_modules/express/node_modules/mime:mime@1.2.1:::: |
|||
/Users/isaacs/dev-src/js/npm/node_modules/express/node_modules/qs:qs@0.0.7:::: |
|||
</code></pre> |
|||
|
|||
<p>And, if you want to get at the globally-installed modules, you can use ls with the global flag:</p> |
|||
|
|||
<pre style="background:#333;color:#ccc;overflow:auto;padding:2px;"><code>$ npm ls -g |
|||
/usr/local |
|||
├─┬ A@1.2.3 -> /Users/isaacs/dev-src/js/A |
|||
│ ├── B@1.2.3 -> /Users/isaacs/dev-src/js/B |
|||
│ └─┬ npm@0.3.15 |
|||
│ └── semver@1.0.1 |
|||
├─┬ B@1.2.3 -> /Users/isaacs/dev-src/js/B |
|||
│ └── A@1.2.3 -> /Users/isaacs/dev-src/js/A |
|||
├── glob@2.0.5 |
|||
├─┬ npm@1.0.0 -> /Users/isaacs/dev-src/js/npm |
|||
│ ├── semver@1.0.1 |
|||
│ └─┬ ronn@0.3.5 |
|||
│ └── opts@1.2.1 |
|||
└── supervisor@0.1.2 -> /Users/isaacs/dev-src/js/node-supervisor |
|||
|
|||
$ npm ls -gpl |
|||
/usr/local::::: |
|||
/usr/local/lib/node_modules/A:A@1.2.3::::/Users/isaacs/dev-src/js/A |
|||
/usr/local/lib/node_modules/A/node_modules/npm:npm@0.3.15::::/Users/isaacs/dev-src/js/A/node_modules/npm |
|||
/usr/local/lib/node_modules/A/node_modules/npm/node_modules/semver:semver@1.0.1::::/Users/isaacs/dev-src/js/A/node_modules/npm/node_modules/semver |
|||
/usr/local/lib/node_modules/B:B@1.2.3::::/Users/isaacs/dev-src/js/B |
|||
/usr/local/lib/node_modules/glob:glob@2.0.5:::: |
|||
/usr/local/lib/node_modules/npm:npm@1.0.0::::/Users/isaacs/dev-src/js/npm |
|||
/usr/local/lib/node_modules/npm/node_modules/semver:semver@1.0.1::::/Users/isaacs/dev-src/js/npm/node_modules/semver |
|||
/usr/local/lib/node_modules/npm/node_modules/ronn:ronn@0.3.5::::/Users/isaacs/dev-src/js/npm/node_modules/ronn |
|||
/usr/local/lib/node_modules/npm/node_modules/ronn/node_modules/opts:opts@1.2.1::::/Users/isaacs/dev-src/js/npm/node_modules/ronn/node_modules/opts |
|||
/usr/local/lib/node_modules/supervisor:supervisor@0.1.2::::/Users/isaacs/dev-src/js/node-supervisor |
|||
</code></pre> |
|||
|
|||
<p>Those <code>-></code> flags are indications that the package is link-installed, which will be covered in the next installment.</p> |
|||
@ -1,134 +0,0 @@ |
|||
category: npm |
|||
title: Peer Dependencies |
|||
date: 2013-02-08T00:00:00Z |
|||
author: Domenic Denicola |
|||
slug: peer-dependencies |
|||
|
|||
<i>Reposted from [Domenic's |
|||
blog](http://domenic.me/2013/02/08/peer-dependencies/) with |
|||
permission. Thanks!</i> |
|||
|
|||
npm is awesome as a package manager. In particular, it handles sub-dependencies very well: if my package depends on |
|||
`request` version 2 and `some-other-library`, but `some-other-library` depends on `request` version 1, the resulting |
|||
dependency graph looks like: |
|||
|
|||
```text |
|||
├── request@2.12.0 |
|||
└─┬ some-other-library@1.2.3 |
|||
└── request@1.9.9 |
|||
``` |
|||
|
|||
This is, generally, great: now `some-other-library` has its own copy of `request` v1 that it can use, while not |
|||
interfering with my package's v2 copy. Everyone's code works! |
|||
|
|||
## The Problem: Plugins |
|||
|
|||
There's one use case where this falls down, however: *plugins*. A plugin package is meant to be used with another "host" |
|||
package, even though it does not always directly *use* the host package. There are many examples of this pattern in the |
|||
Node.js package ecosystem already: |
|||
|
|||
- Grunt [plugins](http://gruntjs.com/#plugins-all) |
|||
- Chai [plugins](http://chaijs.com/plugins) |
|||
- LevelUP [plugins](https://github.com/rvagg/node-levelup/wiki/Modules) |
|||
- Express [middleware](http://expressjs.com/api.html#middleware) |
|||
- Winston [transports](https://github.com/flatiron/winston/blob/master/docs/transports.md) |
|||
|
|||
Even if you're not familiar with any of those use cases, surely you recall "jQuery plugins" from back when you were a |
|||
client-side developer: little `<script>`s you would drop into your page that would attach things to `jQuery.prototype` |
|||
for your later convenience. |
|||
|
|||
In essence, plugins are designed to be used with host packages. But more importantly, they're designed to be used with |
|||
*particular versions* of host packages. For example, versions 1.x and 2.x of my `chai-as-promised` plugin work with |
|||
`chai` version 0.5, whereas versions 3.x work with `chai` 1.x. Or, in the faster-paced and less-semver–friendly world of |
|||
Grunt plugins, version 0.3.1 of `grunt-contrib-stylus` works with `grunt` 0.4.0rc4, but breaks when used with `grunt` |
|||
0.4.0rc5 due to removed APIs. |
|||
|
|||
As a package manager, a large part of npm's job when installing your dependencies is managing their versions. But its |
|||
usual model, with a `"dependencies"` hash in `package.json`, clearly falls down for plugins. Most plugins never actually |
|||
depend on their host package, i.e. grunt plugins never do `require("grunt")`, so even if plugins did put down their host |
|||
package as a dependency, the downloaded copy would never be used. So we'd be back to square one, with your application |
|||
possibly plugging in the plugin to a host package that it's incompatible with. |
|||
|
|||
Even for plugins that do have such direct dependencies, probably due to the host package supplying utility APIs, |
|||
specifying the dependency in the plugin's `package.json` would result in a dependency tree with multiple copies of the |
|||
host package—not what you want. For example, let's pretend that `winston-mail` 0.2.3 specified `"winston": "0.5.x"` in |
|||
its `"dependencies"` hash, since that's the latest version it was tested against. As an app developer, you want the |
|||
latest and greatest stuff, so you look up the latest versions of `winston` and of `winston-mail`, putting them in your |
|||
`package.json` as |
|||
|
|||
```json |
|||
{ |
|||
"dependencies": { |
|||
"winston": "0.6.2", |
|||
"winston-mail": "0.2.3" |
|||
} |
|||
} |
|||
``` |
|||
|
|||
But now, running `npm install` results in the unexpected dependency graph of |
|||
|
|||
```text |
|||
├── winston@0.6.2 |
|||
└─┬ winston-mail@0.2.3 |
|||
└── winston@0.5.11 |
|||
``` |
|||
|
|||
I'll leave the subtle failures that come from the plugin using a different Winston API than the main application to |
|||
your imagination. |
|||
|
|||
## The Solution: Peer Dependencies |
|||
|
|||
What we need is a way of expressing these "dependencies" between plugins and their host package. Some way of saying, "I |
|||
only work when plugged in to version 1.2.x of my host package, so if you install me, be sure that it's alongside a |
|||
compatible host." We call this relationship a *peer dependency*. |
|||
|
|||
The peer dependency idea has been kicked around for [literally](https://github.com/isaacs/npm/issues/930) |
|||
[years](https://github.com/isaacs/npm/issues/1400). After |
|||
[volunteering](https://github.com/isaacs/npm/issues/1400#issuecomment-5932027) to get this done "over the weekend" nine |
|||
months ago, I finally found a free weekend, and now peer dependencies are in npm! |
|||
|
|||
Specifically, they were introduced in a rudimentary form in npm 1.2.0, and refined over the next few releases into |
|||
something I'm actually happy with. Today Isaac packaged up npm 1.2.10 into |
|||
[Node.js 0.8.19](http://blog.nodejs.org/2013/02/06/node-v0-8-19-stable/), so if you've installed the latest version of |
|||
Node, you should be ready to use peer dependencies! |
|||
|
|||
As proof, I present you the results of trying to install [`jitsu`](https://npmjs.org/package/jitsu) 0.11.6 with npm |
|||
1.2.10: |
|||
|
|||
```text |
|||
npm ERR! peerinvalid The package flatiron does not satisfy its siblings' peerDependencies requirements! |
|||
npm ERR! peerinvalid Peer flatiron-cli-config@0.1.3 wants flatiron@~0.1.9 |
|||
npm ERR! peerinvalid Peer flatiron-cli-users@0.1.4 wants flatiron@~0.3.0 |
|||
``` |
|||
|
|||
As you can see, `jitsu` depends on two Flatiron-related packages, which themselves peer-depend on conflicting versions |
|||
of Flatiron. Good thing npm was around to help us figure out this conflict, so it could be fixed in version 0.11.7! |
|||
|
|||
## Using Peer Dependencies |
|||
|
|||
Peer dependencies are pretty simple to use. When writing a plugin, figure out what version of the host package you |
|||
peer-depend on, and add it to your `package.json`: |
|||
|
|||
```json |
|||
{ |
|||
"name": "chai-as-promised", |
|||
"peerDependencies": { |
|||
"chai": "1.x" |
|||
} |
|||
} |
|||
``` |
|||
|
|||
Now, when installing `chai-as-promised`, the `chai` package will come along with it. And if later you try to install |
|||
another Chai plugin that only works with 0.x versions of Chai, you'll get an error. Nice! |
|||
|
|||
One piece of advice: peer dependency requirements, unlike those for regular dependencies, *should be lenient*. You |
|||
should not lock your peer dependencies down to specific patch versions. It would be really annoying if one Chai plugin |
|||
peer-depended on Chai 1.4.1, while another depended on Chai 1.5.0, simply because the authors were lazy and didn't spend |
|||
the time figuring out the actual minimum version of Chai they are compatible with. |
|||
|
|||
The best way to determine what your peer dependency requirements should be is to actually follow |
|||
[semver](http://semver.org/). Assume that only changes in the host package's major version will break your plugin. Thus, |
|||
if you've worked with every 1.x version of the host package, use `"~1.0"` or `"1.x"` to express this. If you depend on |
|||
features introduced in 1.5.2, use `">= 1.5.2 < 2"`. |
|||
|
|||
Now go forth, and peer depend! |
|||
@ -1,43 +0,0 @@ |
|||
version: 0.6.21 |
|||
title: Version 0.6.21 (maintenance) |
|||
category: release |
|||
slug: node-v0-6-21-maintenance |
|||
date: Fri Aug 03 2012 14:44:02 GMT-0700 (PDT) |
|||
|
|||
2012.08.03 Version 0.6.21 (maintenance) |
|||
|
|||
* sunos: work around OS bug to prevent fs.watch() from spinning (Bryan Cantrill) |
|||
|
|||
* net: make pause/resume work with connecting sockets (Bert Belder) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.6.21/node-v0.6.21.tar.gz |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.6.21/node-v0.6.21.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.6.21/x64/ |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.6.21/node-v0.6.21.pkg |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.6.21/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.6.21/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.6.21/api/ |
|||
|
|||
Shasums: |
|||
|
|||
``` |
|||
04f58b0da23c3db291d84ac55a924332ad83c427 node-v0.6.21.pkg |
|||
31f564bf34c64b07cae3b9a88a87b4a08bab4dc5 node-v0.6.21.tar.gz |
|||
1e3184fe2cfe7140a88b5dcc9c2ec7d32f1f5af5 node.exe |
|||
b8887a056152622c08ee10f5867bd27910260477 node.exp |
|||
c6468ffe2e145e7db1bb3e2d66adb9f5d50271ad node.lib |
|||
2a896bcb7c83f2fa710650116580daf4ac5e6c4c node.msi |
|||
207441e8c3dc184c478367b775dc7ece1ee36501 node.pdb |
|||
715ad9946db5f97c54a53bdea6bbe9ba69f2f299 x64/node.exe |
|||
2fa2c2d82fedeec1ed8be5d908b790f473d4a7c2 x64/node.exp |
|||
b403cb71d4cf21e97a78d446403cedc9795bcf69 x64/node.lib |
|||
ef47520dbc6a1a68ec37d290c421031cfd670048 x64/node.msi |
|||
fb15e3991c420f3ae67ade92b11b07bb9112124a x64/node.pdb |
|||
``` |
|||
@ -1,25 +0,0 @@ |
|||
version: 0.4.10 |
|||
title: Node v0.4.10 |
|||
author: ryandahl |
|||
date: Wed Jul 20 2011 07:36:38 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-4-10 |
|||
|
|||
2011.07.19, Version 0.4.10 (stable) |
|||
<ul><li>#394 Fix Buffer drops last null character in UTF-8 |
|||
<li>#829 Backport r8577 from V8 (Ben Noordhuis) |
|||
<li>#877 Don't wait for HTTP Agent socket pool to establish connections. |
|||
<li>#915 Find kqueue on FreeBSD correctly (Brett Kiefer) |
|||
<li>#1085 HTTP: Fix race in abort/dispatch code (Stefan Rusu) |
|||
<li>#1274 debugger improvement (Yoshihiro Kikuchi) |
|||
<li>#1291 Properly respond to HEAD during end(body) hot path (Reid Burke) |
|||
<li>#1304 TLS: Fix race in abort/connection code (Stefan Rusu) |
|||
<li>#1360 Allow _ in url hostnames. |
|||
<li>Revert 37d529f8 - unbreaks debugger command parsing. |
|||
<li>Bring back global execScript |
|||
<li>Doc improvements</ul> |
|||
|
|||
Download: <a href="http://nodejs.org/dist/node-v0.4.10.tar.gz">http://nodejs.org/dist/node-v0.4.10.tar.gz</a> |
|||
Website: <a href="http://nodejs.org/docs/v0.4.10">http://nodejs.org/docs/v0.4.10</a> |
|||
Documentation: <a href="http://nodejs.org/docs/v0.4.10/api">http://nodejs.org/docs/v0.4.10/api</a> |
|||
@ -1,39 +0,0 @@ |
|||
version: 0.4.11 |
|||
title: Node v0.4.11 |
|||
author: ryandahl |
|||
date: Thu Aug 18 2011 01:44:42 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-4-11 |
|||
|
|||
2011.08.17, Version 0.4.11 (stable) |
|||
<ul><li><a href="http://github.com/joyent/node/issues/738">#738</a> Fix crypto encryption/decryption with Base64. (SAWADA Tadashi) |
|||
|
|||
<li><a href="http://github.com/joyent/node/issues/1202">#1202</a> net.createConnection defer DNS lookup error events to next tick (Ben Noordhuis) |
|||
|
|||
<li><a href="http://github.com/joyent/node/issues/1374">#1374</a> fix setting ServerResponse.statusCode in writeHead (Trent Mick) |
|||
|
|||
<li><a href="http://github.com/joyent/node/issues/1417">#1417</a> Fix http.ClientRequest crashes if end() was called twice |
|||
|
|||
<li><a href="http://github.com/joyent/node/issues/1497">#1497</a> querystring: Replace 'in' test with 'hasOwnProperty' (isaacs) |
|||
|
|||
<li><a href="http://github.com/joyent/node/issues/1546">#1546</a> http perf improvement |
|||
|
|||
<li>fix memleak in libeio (Tom Hughes) |
|||
|
|||
<li>cmake improvements (Tom Hughes) |
|||
|
|||
<li>node_net.cc: fix incorrect sizeof() (Tom Hughes) |
|||
|
|||
<li>Windows/cygwin: no more GetConsoleTitleW errors on XP (Bert Belder) |
|||
|
|||
<li>Doc improvements (koichik, Logan Smyth, Ben Noordhuis, Arnout Kazemier)</ul> |
|||
|
|||
|
|||
|
|||
|
|||
Download: <a href="http://nodejs.org/dist/node-v0.4.11.tar.gz">http://nodejs.org/dist/node-v0.4.11.tar.gz</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.4.11/">http://nodejs.org/docs/v0.4.11/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.4.11/api/">http://nodejs.org/docs/v0.4.11/api/</a> |
|||
@ -1,29 +0,0 @@ |
|||
version: 0.4.12 |
|||
title: Node v0.4.12 |
|||
author: ryandahl |
|||
date: Thu Sep 15 2011 17:32:07 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-4-12 |
|||
|
|||
2011.09.15, Version 0.4.12 (stable) |
|||
|
|||
<ul> |
|||
<li>Improve docs |
|||
<li>#1563 overflow in ChildProcess custom_fd. |
|||
<li>#1569, parse error on multi-line HTTP headers. (Ben Noordhuis) |
|||
<li>#1586 net: Socket write encoding case sensitivity (koichik) |
|||
<li>#1610 Remove DigiNotar CA from trusted list (isaacs) |
|||
<li>#1624 buffer: Avoid overrun with 'binary' encoding. (koichik) |
|||
<li>#1633 buffer: write() should always set _charsWritten. (koichik) |
|||
<li>#1707 hasOwnProperty usage security hole in querystring (isaacs) |
|||
<li>#1719 Drain OpenSSL error queue |
|||
<li>Fix error reporting in net.Server.listen</ul> |
|||
|
|||
|
|||
|
|||
Download: <a href="http://nodejs.org/dist/node-v0.4.12.tar.gz">http://nodejs.org/dist/node-v0.4.12.tar.gz</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.4.12/">http://nodejs.org/docs/v0.4.12/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.4.12/api/">http://nodejs.org/docs/v0.4.12/api/</a> |
|||
@ -1,33 +0,0 @@ |
|||
version: 0.4.3 |
|||
title: Node v0.4.3 |
|||
author: ryandahl |
|||
date: Fri Mar 18 2011 22:17:59 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-4-3 |
|||
|
|||
2011.03.18, Version 0.4.3 (stable) |
|||
<ul> |
|||
<li> Don't decrease server connection counter again if destroy() is called more than once GH-431 (Andreas Reich, Anders Conbere) |
|||
<li> Documentation improvements (koichik) |
|||
<li> Fix bug with setMaxListeners GH-682 |
|||
<li> Start up memory footprint improvement. (Tom Hughes) |
|||
<li> Solaris improvements. |
|||
<li> Buffer::Length(Buffer*) should not invoke itself recursively GH-759 (Ben Noordhuis) |
|||
<li> TLS: Advertise support for client certs GH-774 (Theo Schlossnagle) |
|||
<li> HTTP Agent bugs: GH-787, GH-784, GH-803. |
|||
<li> Don't call GetMemoryUsage every 5 seconds. |
|||
<li> Upgrade V8 to 3.1.8.3 |
|||
</ul> |
|||
|
|||
|
|||
|
|||
Download: http://nodejs.org/dist/node-v0.4.3.tar.gz |
|||
|
|||
Website: http://nodejs.org/docs/v0.4.3/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.4.3/api |
|||
|
|||
<a href="https://groups.google.com/d/topic/nodejs/JrYQCQtf6lM/discussion">Announcement</a> |
|||
|
|||
<a href="https://github.com/joyent/node/tree/v0.4.3">commit</a> |
|||
@ -1,27 +0,0 @@ |
|||
version: 0.4.4 |
|||
title: Node v0.4.4 |
|||
author: ryandahl |
|||
date: Sat Mar 26 2011 08:58:45 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-4-4 |
|||
|
|||
2011.03.26, Version 0.4.4 (stable) |
|||
<ul> |
|||
<li> CryptoStream.end shouldn't throw if not writable GH-820 |
|||
<li> Drop out if connection destroyed before connect() GH-819 |
|||
<li> expose https.Agent |
|||
<li> Correctly setsid in tty.open GH-815 |
|||
<li> Bug fix for failed buffer construction |
|||
<li> Added support for removing .once listeners (GH-806) |
|||
<li> Upgrade V8 to 3.1.8.5</ul> |
|||
|
|||
|
|||
|
|||
Download: <a href="http://nodejs.org/dist/node-v0.4.4.tar.gz">http://nodejs.org/dist/node-v0.4.4.tar.gz</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.4.4/">http://nodejs.org/docs/v0.4.4</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.4.4/api/">http://nodejs.org/docs/v0.4.4/api</a> |
|||
|
|||
<a href="https://groups.google.com/d/topic/nodejs/LlQCYhDEPAc/discussion">announcement</a> |
|||
@ -1,29 +0,0 @@ |
|||
version: 0.4.5 |
|||
title: node v0.4.5 |
|||
author: ryandahl |
|||
date: Sat Apr 02 2011 02:04:58 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-4-5 |
|||
|
|||
2011.04.01, Version 0.4.5 (stable) |
|||
<ul> |
|||
<li> Fix listener leak in stream.pipe() (Mikeal Rogers) |
|||
<li> Retain buffers in fs.read/write() GH-814 (Jorge Chamorro Bieling) |
|||
<li> TLS performance improvements |
|||
<li> SlowBuffer.prototype.slice bug GH-843 |
|||
<li> process.stderr.write should return true |
|||
<li> Immediate pause/resume race condition GH-535 (isaacs) |
|||
<li> Set default host header properly GH-721 (isaacs) |
|||
<li> Upgrade V8 to 3.1.8.8</ul> |
|||
|
|||
|
|||
|
|||
Download: <a href="http://nodejs.org/dist/node-v0.4.5.tar.gz">http://nodejs.org/dist/node-v0.4.5.tar.gz</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.4.5">http://nodejs.org/docs/v0.4.5</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.4.5/api">http://nodejs.org/docs/v0.4.5/api</a> |
|||
|
|||
|
|||
<a href="https://groups.google.com/d/topic/nodejs/aOC7SRLJhQY/discussion">announcement</a> |
|||
@ -1,27 +0,0 @@ |
|||
version: 0.4.6 |
|||
title: Node v0.4.6 |
|||
author: ryandahl |
|||
date: Thu Apr 14 2011 05:00:30 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-4-6 |
|||
|
|||
2011.04.13, Version 0.4.6 (stable) |
|||
<ul><li> Don't error on ENOTCONN from shutdown() #670 |
|||
<li> Auto completion of built-in debugger suggests prefix match rather than partial match. (koichik) |
|||
<li> circular reference in vm modules. #822 (Jakub Lekstan) |
|||
<li> http response.readable should be false after 'end' #867 (Abe Fettig) |
|||
<li> Implement os.cpus() and os.uptime() on Solaris (Scott McWhirter) |
|||
<li> fs.ReadStream: Allow omission of end option for range reads #801 (Felix Geisendörfer) |
|||
<li> Buffer.write() with UCS-2 should not be write partial char #916 (koichik) |
|||
<Li> Pass secureProtocol through on tls.Server creation (Theo Schlossnagle) |
|||
<li> TLS use RC4-SHA by default |
|||
<li> Don't strangely drop out of event loop on HTTPS client uploads #892 |
|||
<li> Doc improvements |
|||
<li> Upgrade v8 to 3.1.8.10</ul> |
|||
|
|||
Download: <a href="http://nodejs.org/dist/node-v0.4.6.tar.gz">http://nodejs.org/dist/node-v0.4.6.tar.gz</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.4.6/">http://nodejs.org/docs/v0.4.6/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.4.6/api/">http://nodejs.org/docs/v0.4.6/api/</a> |
|||
@ -1,23 +0,0 @@ |
|||
version: 0.4.7 |
|||
title: Node v0.4.7 |
|||
author: ryandahl |
|||
date: Sat Apr 23 2011 00:47:55 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-4-7 |
|||
|
|||
2011.04.22, Version 0.4.7 (stable) |
|||
<ul><li> Don't emit error on ECONNRESET from read() #670 |
|||
<li> Fix: Multiple pipes to the same stream were broken #929 (Felix Geisendörfer) |
|||
<li> URL parsing/formatting corrections #954 (isaacs) |
|||
<li> make it possible to do repl.start('', stream) (Wade Simmons) |
|||
<li> Add os.loadavg for SunOS (Robert Mustacchi) |
|||
<li> Fix timeouts with floating point numbers #897 (Jorge Chamorro Bieling) |
|||
<li> Improve docs.</ul> |
|||
|
|||
|
|||
Download: <a href="http://nodejs.org/dist/node-v0.4.7.tar.gz">http://nodejs.org/dist/node-v0.4.7.tar.gz</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.4.7/">http://nodejs.org/docs/v0.4.7/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.4.7/api">http://nodejs.org/docs/v0.4.7/api</a> |
|||
@ -1,55 +0,0 @@ |
|||
version: 0.4.8 |
|||
title: Node v0.4.8 |
|||
author: ryandahl |
|||
date: Sat May 21 2011 07:06:00 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-4-8 |
|||
|
|||
2011.05.20, Version 0.4.8 (stable) |
|||
|
|||
* #974 Properly report traceless errors (isaacs) |
|||
|
|||
* #983 Better JSON.parse error detection in REPL (isaacs) |
|||
|
|||
* #836 Agent socket errors bubble up to req only if req exists |
|||
|
|||
* #1041 Fix event listener leak check timing (koichik) |
|||
|
|||
* #1038 Fix dns.resolve() with 'PTR' throws Error: Unknown type "PTR" |
|||
(koichik) |
|||
|
|||
* #1073 Share SSL context between server connections (Fedor Indutny) |
|||
|
|||
* Disable compression with OpenSSL. Improves memory perf. |
|||
|
|||
* Implement os.totalmem() and os.freemem() for SunOS (Alexandre Marangone) |
|||
|
|||
* Fix a special characters in URL regression (isaacs) |
|||
|
|||
* Fix idle timeouts in HTTPS (Felix Geisendörfer) |
|||
|
|||
* SlowBuffer.write() with 'ucs2' throws ReferenceError. (koichik) |
|||
|
|||
* http.ServerRequest 'close' sometimes gets an error argument |
|||
(Felix Geisendörfer) |
|||
|
|||
* Doc improvements |
|||
|
|||
* cleartextstream.destroy() should close(2) the socket. Previously was being |
|||
mapped to a shutdown(2) syscall. |
|||
|
|||
* No longer compile out asserts and debug statements in normal build. |
|||
|
|||
* Debugger improvements. |
|||
|
|||
* Upgrade V8 to 3.1.8.16. |
|||
|
|||
|
|||
|
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.4.8/">http://nodejs.org/docs/v0.4.8/</a> |
|||
|
|||
Download: <a href="http://nodejs.org/dist/node-v0.4.8.tar.gz">http://nodejs.org/dist/node-v0.4.8.tar.gz</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.4.8/api/">http://nodejs.org/docs/v0.4.8/api/</a> |
|||
@ -1,30 +0,0 @@ |
|||
version: 0.4.9 |
|||
title: Node v0.4.9 |
|||
author: ryandahl |
|||
date: Wed Jun 29 2011 11:41:05 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-4-9 |
|||
|
|||
2011.06.29, Version 0.4.9 (stable)<ul> |
|||
<li> Improve documentation |
|||
<li> #1095 error handling bug in stream.pipe() (Felix Geisendörfer) |
|||
<li> #1097 Fix a few leaks in node_crypto.cc (Ben Noordhuis) |
|||
<li> #562 #1078 Parse file:// urls properly (Ryan Petrello) |
|||
<li> #880 Option to disable SSLv2 (Jérémy Lal) |
|||
<li> #1087 Disabling SSL compression disabled with early OpenSSLs. |
|||
<li> #1144 debugger: don't allow users to input non-valid commands (Siddharth Mahendraker) |
|||
<li> Perf improvement for util.inherits |
|||
<li> #1166 Support for signature verification with RSA/DSA public keys (Mark Cavage) |
|||
<li> #1177 Remove node_modules lookup optimization to better support nested project structures (Mathias Buus) |
|||
<li> #1203 Add missing scope.Close to fs.sendfileSync |
|||
<li> #1187 Support multiple 'link' headers |
|||
<li> #1196 Fix -e/--eval can't load module from node_modules (Koichi Kobayashi) |
|||
<li> Upgrade V8 to 3.1.8.25, upgrade http-parser.</ul> |
|||
|
|||
|
|||
Download: <a href="http://nodejs.org/dist/node-v0.4.9.tar.gz">http://nodejs.org/dist/node-v0.4.9.tar.gz</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.4.9">http://nodejs.org/docs/v0.4.9</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.4.9/api">http://nodejs.org/docs/v0.4.9/api</a> |
|||
@ -1,39 +0,0 @@ |
|||
version: 0.5.0 |
|||
title: Node v0.5.0 (Unstable) |
|||
author: ryandahl |
|||
date: Wed Jul 06 2011 02:23:17 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-5-0-unstable |
|||
|
|||
2011.07.05, Version 0.5.0 (unstable) |
|||
|
|||
<li> New non-default libuv backend to support IOCP on Windows. Use <code>--use-uv</code> to enable. |
|||
<li> deprecate http.cat |
|||
<li> docs improved. |
|||
<li> add child_process.fork |
|||
<li> add fs.utimes() and fs.futimes() support (Ben Noordhuis) |
|||
<li> add process.uptime() (Tom Huges) |
|||
<li> add path.relative (Tony Huang) |
|||
<li> add os.getNetworkInterfaces() |
|||
<li> add remoteAddress and remotePort for client TCP connections (Brian White) |
|||
<li> add secureOptions flag, setting ciphers, SSL_OP_CRYPTOPRO_TLSEXT_BUG to TLS (Theo Schlossnagle) |
|||
<li> add process.arch (Nathan Rajlich) |
|||
<li> add reading/writing of floats and doubles from/to buffers (Brian White) |
|||
<li> Allow script to be read from stdin |
|||
<li> #477 add Buffer::fill method to do memset (Konstantin Käfer) |
|||
<li> #573 Diffie-Hellman support to crypto module (Håvard Stranden) |
|||
<li> #695 add 'hex' encoding to buffer (isaacs) |
|||
<li> #851 Update how REPLServer uses contexts (Ben Weaver) |
|||
<li> #853 add fs.lchow, fs.lchmod, fs.fchmod, fs.fchown (isaacs) |
|||
<li> #889 Allow to remove all EventEmitter listeners at once (Felix Geisendörfer) |
|||
<li> #926 OpenSSL NPN support (Fedor Indutny) |
|||
<li> #955 Change ^C handling in REPL (isaacs) |
|||
<li> #979 add support for Unix Domain Sockets to HTTP (Mark Cavage) |
|||
<li> #1173 #1170 add AMD, asynchronous module definition (isaacs) |
|||
<li> DTrace probes: support X-Forwarded-For (Dave Pacheco) </ul> |
|||
Download: <a href="http://nodejs.org/dist/node-v0.5.0.tar.gz">http://nodejs.org/dist/node-v0.5.0.tar.gz</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.5.0/">http://nodejs.org/docs/v0.5.0/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.5.0/api/">http://nodejs.org/docs/v0.5.0/api/</a> |
|||
@ -1,30 +0,0 @@ |
|||
version: 0.5.1 |
|||
title: Node v0.5.1 |
|||
author: ryandahl |
|||
date: Thu Jul 14 2011 23:48:08 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-5-1 |
|||
|
|||
2011.07.14, Version 0.5.1 (unstable) |
|||
<ul><li> #1233 Fix os.totalmem on FreeBSD amd64 (Artem Zaytsev) |
|||
<li> #1149 IDNA and Punycode support in url.parse (Jeremy Selier, Ben Noordhuis, isaacs) |
|||
<li> Export $CC and $CXX to uv and V8's build systems |
|||
<li> Include pthread-win32 static libraries in build (Igor Zinkovsky) |
|||
<li> #1199, #1094 Fix fs can't handle large file on 64bit platform (koichik) |
|||
<li> #1281 Make require a public member of module (isaacs) |
|||
<li> #1303 Stream.pipe returns the destination (Elijah Insua) |
|||
<li> #1229 Addons should not -DEV_MULTIPLICITY=0 (Brian White) |
|||
<li> libuv backend improvements |
|||
<li> Upgrade V8 to 3.4.10</ul> |
|||
|
|||
|
|||
|
|||
|
|||
Download: <a href="http://nodejs.org/dist/v0.5.1/node-v0.5.1.tar.gz">http://nodejs.org/dist/v0.5.1/node-v0.5.1.tar.gz</a> |
|||
|
|||
Windows Build: <a href="http://nodejs.org/dist/v0.5.1/node.exe">http://nodejs.org/dist/v0.5.1/node.exe</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/dist/v0.5.1/docs/api/">http://nodejs.org/dist/v0.5.1/docs/api/</a> |
|||
|
|||
Website: <a href="http://nodejs.org/dist/v0.5.1/docs">http://nodejs.org/dist/v0.5.1/docs</a> |
|||
@ -1,41 +0,0 @@ |
|||
version: 0.5.10 |
|||
title: Node v0.5.10 |
|||
author: ryandahl |
|||
date: Fri Oct 21 2011 19:12:31 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-5-10 |
|||
|
|||
2011.10.21, Version 0.5.10 (unstable) |
|||
<ul><li>Remove cmake build system, support for Cygwin, legacy code base, process.ENV, process.ARGV, process.memoryUsage().vsize, os.openOSHandle</li> |
|||
<li>Documentation improvments (Igor Zinkovsky, Bert Belder, Ilya Dmitrichenko, koichik, Maciej Małecki, Guglielmo Ferri, isaacs)</li> |
|||
<li>Performance improvements (Daniel Ennis, Bert Belder, Ben Noordhuis) </li> |
|||
<li>Long process.title support (Ben Noordhuis)</li> |
|||
<li>net: register net.Server callback only once (Simen Brekken)</li> |
|||
<li>net: fix connect queue bugs (Ben Noordhuis)</li> |
|||
<li>debugger: fix backtrace err handling (Fedor Indutny)</li> |
|||
<li>Use getaddrinfo instead of c-ares for dns.lookup</li> |
|||
<li>Emit 'end' from crypto streams on close</li> |
|||
<li>repl: print out `undefined` (Nathan Rajlich)</li> |
|||
<li>#1902 buffer: use NO_NULL_TERMINATION flag (koichik)</li> |
|||
<li>#1907 http: Added support for HTTP PATCH verb (Thomas Parslow)</li> |
|||
<li>#1644 add GetCPUInfo on windows (Karl Skomski)</li> |
|||
<li>#1484, #1834, #1482, #771 Don't use a separate context for the repl. (isaacs)</li> |
|||
<li>#1882 zlib Update 'availOutBefore' value, and test (isaacs)</li> |
|||
<li>#1888 child_process.fork: don't modify args (koichik)</li> |
|||
<li>#1516 tls: requestCert unusable with Firefox and Chrome (koichik)</li> |
|||
<li>#1467 tls: The TLS API is inconsistent with the TCP API (koichik)</li> |
|||
<li>#1894 net: fix error handling in listen() (koichik)</li> |
|||
<li>#1860 console.error now goes through uv_tty_t</li> |
|||
<li>Upgrade V8 to 3.7.0</li> |
|||
<li>Upgrade GYP to r1081</li></ul> |
|||
|
|||
|
|||
|
|||
Download: <a href="http://nodejs.org/dist/v0.5.10/node-v0.5.10.tar.gz">http://nodejs.org/dist/v0.5.10/node-v0.5.10.tar.gz</a> |
|||
|
|||
Windows Executable: <a href="http://nodejs.org/dist/v0.5.10/node.exe">http://nodejs.org/dist/v0.5.10/node.exe</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.5.10/">http://nodejs.org/docs/v0.5.10/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.5.10/api/">http://nodejs.org/docs/v0.5.10/api/</a> |
|||
@ -1,27 +0,0 @@ |
|||
version: 0.5.2 |
|||
title: Node v0.5.2 |
|||
author: ryandahl |
|||
date: Fri Jul 22 2011 11:40:22 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-5-2 |
|||
|
|||
2011.07.22, Version 0.5.2 (unstable) |
|||
<ul><li>libuv improvements; named pipe support |
|||
<li>#1242 check for SSL_COMP_get_compression_methods() (Ben Noordhuis) |
|||
<li>#1348 remove require.paths (isaacs) |
|||
<li>#1349 Delimit NODE_PATH with ; on Windows (isaacs) |
|||
<li>#1335 Remove EventEmitter from C++ |
|||
<li>#1357 Load json files with require() (isaacs) |
|||
<li>#1374 fix setting ServerResponse.statusCode in writeHead (Trent Mick) |
|||
<li>Fixed: GC was being run too often. |
|||
<li>Upgrade V8 to 3.4.14 |
|||
<li>doc improvements</ul> |
|||
|
|||
Download: <a href="http://nodejs.org/dist/v0.5.2/node-v0.5.2.tar.gz">http://nodejs.org/dist/v0.5.2/node-v0.5.2.tar.gz</a> |
|||
|
|||
Windows Executable: <a href="http://nodejs.org/dist/v0.5.2/node.exe">http://nodejs.org/dist/v0.5.2/node.exe</a> |
|||
|
|||
Website: <a href="http://nodejs.org/dist/v0.5.2/docs/">http://nodejs.org/dist/v0.5.2/docs/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/dist/v0.5.2/docs/api">http://nodejs.org/dist/v0.5.2/docs/api</a> |
|||
@ -1,53 +0,0 @@ |
|||
version: 0.5.3 |
|||
title: Node v0.5.3 |
|||
author: ryandahl |
|||
date: Tue Aug 02 2011 08:03:06 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-5-3 |
|||
|
|||
2011.08.01, Version 0.5.3 (unstable) |
|||
|
|||
<ul><li>Fix crypto encryption/decryption with Base64. (SAWADA Tadashi) |
|||
|
|||
<li>#243 Add an optional length argument to Buffer.write() (koichik) |
|||
|
|||
<li>#657 convert nonbuffer data to string in fs.writeFile/Sync (Daniel Pihlström) |
|||
|
|||
<li>Add process.features, remove process.useUV (Ben Noordhuis) |
|||
|
|||
<li>#324 Fix crypto hmac to accept binary keys + add test cases from rfc 2202 and 4231 (Stefan Bühler) |
|||
|
|||
<li>Add Socket::bytesRead, Socket::bytesWritten (Alexander Uvarov) |
|||
|
|||
<li>#572 Don't print result of --eval in CLI (Ben Noordhuis) |
|||
|
|||
<li>#1223 Fix http.ClientRequest crashes if end() was called twice (koichik) |
|||
|
|||
<li>#1383 Emit 'close' after all connections have closed (Felix Geisendörfer) |
|||
|
|||
<li>Add sprintf-like util.format() function (Ben Noordhuis) |
|||
|
|||
<li>Add support for TLS SNI (Fedor Indutny) |
|||
|
|||
<li>New http agent implementation. Off by default the command line flag <code>--use-http2</code> will enable it. <code>make test-http2</code> will run the tests for the new implementation. (Mikeal Rogers) |
|||
|
|||
<li>Revert AMD compatibility. (isaacs) |
|||
|
|||
<li>Windows: improvements, child_process support. |
|||
|
|||
<li>Remove pkg-config file. |
|||
|
|||
<li>Fix startup time regressions. |
|||
|
|||
<li>doc improvements</ul> |
|||
|
|||
|
|||
|
|||
Download: <a href="http://nodejs.org/dist/v0.5.3/node-v0.5.3.tar.gz">http://nodejs.org/dist/v0.5.3/node-v0.5.3.tar.gz</a> |
|||
|
|||
Windows Executable: <a href="http://nodejs.org/dist/v0.5.3/node.exe">http://nodejs.org/dist/v0.5.3/node.exe</a> |
|||
|
|||
Website: <a href="http://nodejs.org/dist/v0.5.3/docs">http://nodejs.org/dist/v0.5.3/docs</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/dist/v0.5.3/docs/api">http://nodejs.org/dist/v0.5.3/docs/api</a> |
|||
@ -1,36 +0,0 @@ |
|||
version: 0.5.4 |
|||
title: Node v0.5.4 |
|||
author: ryandahl |
|||
date: Fri Aug 12 2011 08:38:26 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-5-4 |
|||
|
|||
2011.08.12, Version 0.5.4 (unstable) |
|||
|
|||
<ul><li>libuv/Windows compatibility improvements |
|||
|
|||
<li>Build on Microsoft Visual Studio via GYP. Use generate-projects.bat in the to build sln files. (Peter Bright, Igor Zinkovsky) |
|||
|
|||
<li>Make Mikeal's HTTP agent client the default. Use old HTTP client with <code>--use-http1</code> |
|||
|
|||
<li>Fixes https host header default port handling. (Mikeal Rogers) |
|||
|
|||
<li>#1440 strip byte order marker when loading *.js and *.json files (Ben Noordhuis) |
|||
|
|||
<li>#1434 Improve util.format() compatibility with browser. (Koichi Kobayashi) |
|||
|
|||
<li>Provide unchecked uint entry points for integer Buffer.read/writeInt methods. (Robert Mustacchi) |
|||
|
|||
<li>CMake improvements (Tom Huges) |
|||
|
|||
<li>Upgrade V8 to 3.5.4.</ul> |
|||
|
|||
|
|||
Download: <a href="http://nodejs.org/dist/v0.5.4/node-v0.5.4.tar.gz">http://nodejs.org/dist/v0.5.4/node-v0.5.4.tar.gz</a> |
|||
|
|||
Windows Executable: <a href="http://nodejs.org/dist/v0.5.4/node.exe">http://nodejs.org/dist/v0.5.4/node.exe</a> |
|||
|
|||
Website: <a href="http://nodejs.org/dist/v0.5.4/docs">http://nodejs.org/dist/v0.5.4/docs</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/dist/v0.5.4/docs/api">http://nodejs.org/dist/v0.5.4/docs/api</a> |
|||
@ -1,40 +0,0 @@ |
|||
version: 0.5.5 |
|||
title: Node v0.5.5 |
|||
author: bennoordhuis |
|||
date: Fri Aug 26 2011 23:20:10 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-5-5 |
|||
|
|||
<p>2011.08.26, Version 0.5.5 (unstable)</p> |
|||
<ul> |
|||
<li>typed arrays, implementation from Plesk |
|||
<li>fix IP multicast on SunOS |
|||
<li>fix DNS lookup order: IPv4 first, IPv6 second (--use-uv only) |
|||
<li>remove support for UNIX datagram sockets (--use-uv only) |
|||
<li>UDP support for Windows (Bert Belder) |
|||
<li>#1572 improve tab completion for objects in the REPL (Nathan Rajlich) |
|||
<li>#1563 fix buffer overflow in child_process module (reported by Dean McNamee) |
|||
<li>#1546 fix performance regression in http module (reported by Brian Geffon) |
|||
<li>#1491 add PBKDF2 crypto support (Glen Low) |
|||
<li>#1447 remove deprecated http.cat() function (Mikeal Rogers) |
|||
<li>#1140 fix incorrect dispatch of vm.runInContext's filename argument<br /> |
|||
(Antranig Basman)</p> |
|||
<li>#1140 document vm.runInContext() and vm.createContext() (Antranig Basman) |
|||
<li>#1428 fix os.freemem() on 64 bits freebsd (Artem Zaytsev) |
|||
<li>#1164 make all DNS lookups async, fixes uncatchable exceptions<br /> |
|||
(Koichi Kobayashi)</p> |
|||
<li>fix incorrect ssl shutdown check (Tom Hughes) |
|||
<li>various cmake fixes (Tom Hughes) |
|||
<li>improved documentation (Koichi Kobayashi, Logan Smyth, Fedor Indutny,<br /> |
|||
Mikeal Rogers, Maciej Małecki, Antranig Basman, Mickaël Delahaye)</p> |
|||
<li>upgrade libuv to commit 835782a |
|||
<li>upgrade V8 to 3.5.8 |
|||
</ul> |
|||
<p>Download: <a href="http://nodejs.org/dist/node-v0.5.5.tar.gz">http://nodejs.org/dist/node-v0.5.5.tar.gz</a></p> |
|||
<p>Windows Executable: <a href="http://nodejs.org/dist/v0.5.5/node.exe">http://nodejs.org/dist/v0.5.5/node.exe</a></p> |
|||
<p>Website: <a href="http://nodejs.org/docs/v0.5.5/">http://nodejs.org/docs/v0.5.5/</a></p> |
|||
<p>Documentation: <a href="http://nodejs.org/docs/v0.5.5/api/">http://nodejs.org/docs/v0.5.5/api/</a></p> |
|||
<br /><br /> |
|||
|
|||
<b>Update:</b> The <code>.exe</code> has a bug that results in incompatibility with Windows XP and Server 2003. This has been reported in <a href="https://github.com/joyent/node/issues/1592">issue #1592</a> and fixed. A new binary was made that is compatibile with the older Windows: <a href="http://nodejs.org/dist/v0.5.5/node-186364e.exe">http://nodejs.org/dist/v0.5.5/node-186364e.exe</a>. |
|||
@ -1,49 +0,0 @@ |
|||
version: 0.5.6 |
|||
title: Node v0.5.6 (unstable) |
|||
author: piscisaureus |
|||
date: Fri Sep 09 2011 16:30:39 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-5-6 |
|||
|
|||
2011.09.08, Version 0.5.6 (unstable) |
|||
<ul> |
|||
<li>#345, #1635, #1648 Documentation improvements (Thomas Shinnick, Abimanyu Raja, AJ ONeal, Koichi Kobayashi, Michael Jackson, Logan Smyth, Ben Noordhuis)</li> |
|||
<li>#650 Improve path parsing on windows (Bert Belder)</li> |
|||
<li>#752 Remove headers sent check in OutgoingMessage.getHeader() (Peter Lyons)</li> |
|||
<li>#1236, #1438, #1506, #1513, #1621, #1640, #1647 Libuv-related bugs fixed (Jorge Chamorro Bieling, Peter Bright, Luis Lavena, Igor Zinkovsky)</li> |
|||
<li>#1296, #1612 crypto: Fix BIO's usage. (Koichi Kobayashi)</li> |
|||
<li>#1345 Correctly set socket.remoteAddress with libuv backend (Bert Belder)</li> |
|||
<li>#1429 Don't clobber quick edit mode on windows (Peter Bright)</li> |
|||
<li>#1503 Make libuv backend default on unix, override with `node --use-legacy`</li> |
|||
<li>#1565 Fix fs.stat for paths ending with \ on windows (Igor Zinkovsky)</li> |
|||
<li>#1568 Fix x509 certificate subject parsing (Koichi Kobayashi)</li> |
|||
<li>#1586 Make socket write encoding case-insensitive (Koichi Kobayashi)</li> |
|||
<li>#1591, #1656, #1657 Implement fs in libuv, remove libeio and pthread-win32 dependency on windows (Igor Zinkovsky, Ben Noordhuis, Ryan Dahl, Isaac Schlueter)</li> |
|||
<li>#1592 Don't load-time link against CreateSymbolicLink on windows (Peter Bright)</li> |
|||
<li>#1601 Improve API consistency when dealing with the socket underlying a HTTP client request (Mikeal Rogers)</li> |
|||
<li>#1610 Remove DigiNotar CA from trusted list (Isaac Schlueter)</li> |
|||
<li>#1617 Added some win32 os functions (Karl Skomski)</li> |
|||
<li>#1624 avoid buffer overrun with 'binary' encoding (Koichi Kobayashi)</li> |
|||
<li>#1633 make Buffer.write() always set _charsWritten (Koichi Kobayashi)</li> |
|||
<li>#1644 Windows: set executables to be console programs (Peter Bright)</li> |
|||
<li>#1651 improve inspection for sparse array (Koichi Kobayashi)</li> |
|||
<li>#1672 set .code='ECONNRESET' on socket hang up errors (Ben Noordhuis)</li> |
|||
<li>Add test case for foaf+ssl client certificate (Niclas Hoyer)</li> |
|||
<li>Added RPATH environment variable to override run-time library paths (Ashok Mudukutore)</li> |
|||
<li>Added TLS client-side session resumption support (Sean Cunningham)</li> |
|||
<li>Added additional properties to getPeerCertificate (Nathan Rixham, Niclas Hoyer)</li> |
|||
<li>Don't eval repl command twice when an error is thrown (Nathan Rajlich)</li> |
|||
<li>Improve util.isDate() (Nathan Rajlich)</li> |
|||
<li>Improvements in libuv backend and bindings, upgrade libuv to bd6066cb349a9b3a1b0d87b146ddaee06db31d10</li> |
|||
<li>Show warning when using lib/sys.js (Maciej Malecki)</li> |
|||
<li>Support plus sign in url protocol (Maciej Malecki)</li> |
|||
<li>Upgrade V8 to 3.6.2</li> |
|||
</ul> |
|||
Download: <a href="http://nodejs.org/dist/v0.5.6/node-v0.5.6.tar.gz">http://nodejs.org/dist/v0.5.6/node-v0.5.6.tar.gz</a> |
|||
|
|||
Windows Executable: <a href="http://nodejs.org/dist/v0.5.6/node.exe">http://nodejs.org/dist/v0.5.6/node.exe</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.5.6/">http://nodejs.org/docs/v0.5.6/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.5.6/api/">http://nodejs.org/docs/v0.5.6/api/</a> |
|||
@ -1,35 +0,0 @@ |
|||
version: 0.5.7 |
|||
title: Node v0.5.7 (unstable) |
|||
author: ryandahl |
|||
date: Fri Sep 16 2011 18:57:03 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-5-7-unstable |
|||
|
|||
2011.09.16, Version 0.5.7 (unstable) |
|||
<ul> |
|||
<li>Upgrade V8 to 3.6.4 |
|||
<li>Improve Windows compatibility |
|||
<li>Documentation improvements |
|||
<li>Debugger and REPL improvements (Fedor Indutny) |
|||
<li>Add legacy API support: net.Stream(fd), process.stdout.writable, process.stdout.fd |
|||
<li>Fix mkdir EEXIST handling (isaacs) |
|||
<li>Use net_uv instead of net_legacy for stdio |
|||
<li>Do not load readline from util.inspect |
|||
<li>#1673 Fix bug related to V8 context with accessors (Fedor Indutny) |
|||
<li>#1634 util: Fix inspection for Error (koichik) |
|||
<li>#1645 fs: Add positioned file writing feature to fs.WriteStream (Thomas Shinnick) |
|||
<li>#1637 fs: Unguarded fs.watchFile cache statWatchers checking fixed (Thomas Shinnick) |
|||
<li>#1695 Forward customFds to ChildProcess.spawn |
|||
<li>#1707 Fix hasOwnProperty security problem in querystring (isaacs) |
|||
<li>#1719 Drain OpenSSL error queue</ul> |
|||
|
|||
|
|||
|
|||
Download: <a href="http://nodejs.org/dist/v0.5.7/node-v0.5.7.tar.gz">http://nodejs.org/dist/v0.5.7/node-v0.5.7.tar.gz</a> |
|||
|
|||
Windows Executable: <a href="http://nodejs.org/dist/v0.5.7/node.exe">http://nodejs.org/dist/v0.5.7/node.exe</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.5.7/">http://nodejs.org/docs/v0.5.7/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.5.7/api/">http://nodejs.org/docs/v0.5.7/api/</a> |
|||
@ -1,26 +0,0 @@ |
|||
version: 0.5.8 |
|||
title: Node v0.5.8 |
|||
author: ryandahl |
|||
date: Fri Sep 30 2011 16:47:11 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-5-8 |
|||
|
|||
2011.09.30, Version 0.5.8 (unstable)<ul><li>zlib bindings (isaacs) |
|||
<li>Windows supports TTY ANSI escape codes (Bert Belder) |
|||
<li>Debugger improvements (Fedor Indutny) |
|||
<li>crypto: look up SSL errors with ERR_print_errors() (Ben Noordhuis) |
|||
<li>dns callbacks go through MakeCallback now |
|||
<li>Raise an error when a malformed package.json file is found. (Ben Leslie) |
|||
<li>buffers: handle bad length argument in constructor (Ben Noordhuis) |
|||
<li>#1726, unref process.stdout |
|||
<li>Doc improvements (Ben Noordhuis, Fedor Indutny, koichik) |
|||
<li>Upgrade libuv to fe18438</ul> |
|||
|
|||
Download: <a href="http://nodejs.org/dist/v0.5.8/node-v0.5.8.tar.gz">http://nodejs.org/dist/v0.5.8/node-v0.5.8.tar.gz</a> |
|||
|
|||
Windows Executable: <a href="http://nodejs.org/dist/v0.5.8/node.exe">http://nodejs.org/dist/v0.5.8/node.exe</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.5.8/">http://nodejs.org/docs/v0.5.8/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.5.8/api/">http://nodejs.org/docs/v0.5.8/api/</a> |
|||
@ -1,27 +0,0 @@ |
|||
version: 0.5.9 |
|||
title: Node v0.5.9 |
|||
author: ryandahl |
|||
date: Mon Oct 10 2011 19:06:21 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-5-9 |
|||
|
|||
2011.10.10, Version 0.5.9 (unstable) |
|||
<ul><li>fs.watch interface backed by kqueue, inotify, and ReadDirectoryChangesW (Igor Zinkovsky, Ben Noordhuis)</li> |
|||
<li>add dns.resolveTxt (Christian Tellnes)</li> |
|||
<li>Remove legacy http library (Ben Noordhuis)</li> |
|||
<li>child_process.fork returns and works on Windows. Allows passing handles. (Igor Zinkovsky, Bert Belder)</li> |
|||
<li>#1774 Lint and clean up for --harmony_block_scoping (Tyler Larson, Colton Baker)</li> |
|||
<li>#1813 Fix ctrl+c on Windows (Bert Belder)</li> |
|||
<li>#1844 unbreak --use-legacy (Ben Noordhuis)</li> |
|||
<li>process.stderr now goes through libuv. Both process.stdout and process.stderr are blocking when referencing a TTY.</li> |
|||
<li>net_uv performance improvements (Ben Noordhuis, Bert Belder)</li></ul> |
|||
|
|||
|
|||
Download: <a href="http://nodejs.org/dist/v0.5.9/node-v0.5.9.tar.gz">http://nodejs.org/dist/v0.5.9/node-v0.5.9.tar.gz</a> |
|||
|
|||
Windows Executable: <a href="http://nodejs.org/dist/v0.5.9/node.exe">http://nodejs.org/dist/v0.5.9/node.exe</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.5.9/">http://nodejs.org/docs/v0.5.9/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.5.9/api/">http://nodejs.org/docs/v0.5.9/api/</a> |
|||
@ -1,80 +0,0 @@ |
|||
version: 0.6.0 |
|||
title: Node v0.6.0 |
|||
author: ryandahl |
|||
date: Sat Nov 05 2011 02:07:10 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-6-0 |
|||
|
|||
We are happy to announce the third stable branch of Node v0.6. We will be freezing JavaScript, C++, and binary interfaces for all v0.6 releases. |
|||
|
|||
The major differences between v0.4 and v0.6 are<ul> |
|||
<li>Native Windows support using I/O Completion Ports for sockets. |
|||
<li>Integrated load balancing over multiple processes. <a href="http://nodejs.org/docs/v0.6.0/api/cluster.html">docs</a> |
|||
<li>Better support for IPC between Node instances <a href="http://nodejs.org/docs/v0.6.0/api/child_processes.html#child_process.fork">docs</a> |
|||
<li>Improved command line debugger <a href="http://nodejs.org/docs/v0.6.0/api/debugger.html">docs</a> |
|||
<li>Built-in binding to zlib for compression <a href="http://nodejs.org/docs/v0.6.0/api/zlib.html">docs</a> |
|||
<li>Upgrade v8 from 3.1 to 3.6</ul> |
|||
|
|||
In order to support Windows we reworked much of the core architecture. There was some fear that our work would degrade performance on UNIX systems but this was not the case. Here is a Linux system we benched for demonstration: |
|||
|
|||
<table><tr> <th></th> <th>v0.4.12 (linux)</th><th>v0.6.0 (linux)</th></tr> |
|||
<tr> <td>http_simple.js /bytes/1024</td> <td>5461 r/s</td> <td>6263 r/s</td> </tr> |
|||
<tr> <td>io.js read </td> <td>19.75 mB/s</td> <td>26.63 mB/s</td> </tr> |
|||
<tr> <td>io.js write </td> <td>21.60 mB/s</td> <td>17.40 mB/s</td> </tr> |
|||
<tr> <td>startup.js </td> <td>74.7 ms</td> <td>49.6 ms</td> </tr></table> |
|||
|
|||
Bigger is better in http and io benchmarks, smaller is better in startup. The http benchmark was done with 600 clients on a 10GE network served from three load generation machines. |
|||
|
|||
In the last version of Node, v0.4, we could only run Node on Windows with Cygwin. Therefore we've gotten massive improvements by targeting the native APIs. Benchmarks on the same machine: |
|||
|
|||
<table><tr><th></th><th>v0.4.12 (windows)</th><th>v0.6.0 (windows)</th></tr> |
|||
<tr> <td>http_simple.js /bytes/1024</td> <td>3858 r/s</td> <td>5823 r/s</td> </tr> |
|||
<tr> <td>io.js read </td> <td>12.41 mB/s</td> <td>26.51 mB/s</td> </tr> |
|||
<tr> <td>io.js write </td> <td>12.61 mB/s</td> <td>33.58 mB/s</td> </tr> |
|||
<tr> <td>startup.js </td> <td>152.81 ms</td> <td>52.04 ms</td> </tr></table> |
|||
|
|||
We consider this a good intermediate stage for the Windows port. There is still work to be done. For example, we are not yet providing users with a blessed path for building addon modules in MS Visual Studio. Work will continue in later releases. |
|||
|
|||
For users upgrading code bases from v0.4 to v0.6 <a href="https://github.com/joyent/node/wiki/API-changes-between-v0.4-and-v0.6">we've documented</a> most of the issues that you will run into. Most people find the change painless. Despite the long list of changes most core APIs remain untouched. |
|||
|
|||
Our release cycle will be tightened dramatically now. Expect to see a new stable branch in January. We wish to eventually have our releases in sync with Chrome and V8's 6 week cycle. |
|||
|
|||
Thank you to everyone who contributed code, tests, docs, or sent in bug reports. |
|||
|
|||
Here are the changes between v0.5.12 and v0.6.0: |
|||
|
|||
2011.11.04, Version 0.6.0 (stable) |
|||
<ul><li>print undefined on undefined values in REPL (Nathan Rajlich)</li> |
|||
<li>doc improvements (koichik, seebees, bnoordhuis, Maciej Małecki, Jacob Kragh)</li> |
|||
<li>support native addon loading in windows (Bert Belder)</li> |
|||
<li>rename getNetworkInterfaces() to networkInterfaces() (bnoordhuis)</li> |
|||
<li>add pending accepts knob for windows (igorzi)</li> |
|||
<li>http.request(url.parse(x)) (seebees)</li> |
|||
<li>#1929 zlib Respond to 'resume' events properly (isaacs)</li> |
|||
<li>stream.pipe: Remove resume and pause events</li> |
|||
<li>test fixes for windows (igorzi)</li> |
|||
<li>build system improvements (bnoordhuis)</li> |
|||
<li>#1936 tls: does not emit 'end' from EncryptedStream (koichik)</li> |
|||
<li>#758 tls: add address(), remoteAddress/remotePort</li> |
|||
<li>#1399 http: emit Error object after .abort() (bnoordhuis)</li> |
|||
<li>#1999 fs: make mkdir() default to 0777 permissions (bnoordhuis)</li> |
|||
<li>#2001 fix pipe error codes</li> |
|||
<li>#2002 Socket.write should reset timeout timer</li> |
|||
<li>stdout and stderr are blocking when associated with file too.</li> |
|||
<li>remote debugger support on windows (Bert Belder)</li> |
|||
<li>convenience methods for zlib (Matt Robenolt)</li> |
|||
<li>process.kill support on windows (igorzi)</li> |
|||
<li>process.uptime() support on windows (igorzi)</li> |
|||
<li>Return IPv4 addresses before IPv6 addresses from getaddrinfo</li> |
|||
<li>util.inspect improvements (Nathan Rajlich)</li> |
|||
<li>cluster module api changes</li> |
|||
<li>Downgrade V8 to 3.6.6.6</li></ul> |
|||
|
|||
Download: <a href="http://nodejs.org/dist/v0.6.0/node-v0.6.0.tar.gz">http://nodejs.org/dist/v0.6.0/node-v0.6.0.tar.gz</a> |
|||
|
|||
Windows Executable: <a href="http://nodejs.org/dist/v0.6.0/node.exe">http://nodejs.org/dist/v0.6.0/node.exe</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.6.0/">http://nodejs.org/docs/v0.6.0/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.6.0/api/">http://nodejs.org/docs/v0.6.0/api/</a> |
|||
@ -1,33 +0,0 @@ |
|||
version: 0.6.1 |
|||
title: Node v0.6.1 |
|||
author: ryandahl |
|||
date: Fri Nov 11 2011 15:34:15 GMT-0800 (PST) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-6-1 |
|||
|
|||
2011.11.11, Version 0.6.1 (stable) |
|||
<ul><li>doc improvements (Eric Lovett, Ben Noordhuis, Scott Anderson, Yoji SHIDARA)</li> |
|||
<li>crypto: make thread-safe (Ben Noordhuis)</li> |
|||
<li>fix process.kill error object</li> |
|||
<li>debugger: correctly handle source with multi-byte characters (Shigeki Ohtsu)</li> |
|||
<li>make stdout and stderr non-destroyable (Igor Zinkovsky)</li> |
|||
<li>fs: don't close uninitialized fs.watch handle (Ben Noordhuis)</li> |
|||
<li>#2026 fix man page install on BSDs (Ben Noordhuis)</li> |
|||
<li>#2040 fix unrecognized errno assert in uv_err_name</li> |
|||
<li>#2043 fs: mkdir() should call callback if mode is omitted</li> |
|||
<li>#2045 fs: fix fs.realpath on windows to return on error (Benjamin Pasero)</li> |
|||
<li>#2047 minor cluster improvements</li> |
|||
<li>#2052 readline get window columns correctly</li> |
|||
<li>Upgrade V8 to 3.6.6.7</li></ul> |
|||
|
|||
|
|||
Source Code: <a href="http://nodejs.org/dist/v0.6.1/node-v0.6.1.tar.gz">http://nodejs.org/dist/v0.6.1/node-v0.6.1.tar.gz</a> |
|||
|
|||
Windows Installer: <a href="http://nodejs.org/dist/v0.6.1/node-v0.6.1.msi">http://nodejs.org/dist/v0.6.1/node-v0.6.1.msi</a> |
|||
|
|||
Macintosh Installer: <a href="http://nodejs.org/dist/v0.6.1/node-v0.6.1.pkg">http://nodejs.org/dist/v0.6.1/node-v0.6.1.pkg</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.6.1/">http://nodejs.org/docs/v0.6.1/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.6.1/api/">http://nodejs.org/docs/v0.6.1/api/</a> |
|||
@ -1,30 +0,0 @@ |
|||
version: 0.6.10 |
|||
title: Node v0.6.10 |
|||
author: Isaac Schlueter |
|||
date: Thu Feb 02 2012 17:22:03 GMT-0800 (PST) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-6-10 |
|||
|
|||
<p>2012.02.02, Version 0.6.10 (stable)</p> |
|||
|
|||
<ul> |
|||
<li><p>Update V8 to 3.6.6.20</p></li> |
|||
<li><p>Add npm msysgit bash shim to msi installer (isaacs)</p></li> |
|||
<li><p>buffers: fix intermittent out of bounds error (Ben Noordhuis)</p></li> |
|||
<li><p>buffers: honor length argument in base64 decoder (Ben Noordhuis)</p></li> |
|||
<li><p>windows: Fix path.exists regression (Bert Belder)</p></li> |
|||
<li><p>Make QueryString.parse run faster (Philip Tellis)</p></li> |
|||
<li><p>http: avoid freeing http-parser objects too early (koichik)</p></li> |
|||
<li><p>timers: add v0.4 compatibility hack (Ben Noordhuis)</p></li> |
|||
<li><p>Proper EPERM error code support (Igor Zinkovsky, Brandon Philips)</p></li> |
|||
<li><p>dgram: Implement udp multicast methods on windows (Bert Belder)</p></li> |
|||
</ul><p>Source Code: <a href="http://nodejs.org/dist/v0.6.10/node-v0.6.10.tar.gz">http://nodejs.org/dist/v0.6.10/node-v0.6.10.tar.gz</a></p> |
|||
|
|||
<p>Windows Installer: <a href="http://nodejs.org/dist/v0.6.10/node-v0.6.10.msi">http://nodejs.org/dist/v0.6.10/node-v0.6.10.msi</a></p> |
|||
|
|||
<p>Macintosh Installer: <a href="http://nodejs.org/dist/v0.6.10/node-v0.6.10.pkg">http://nodejs.org/dist/v0.6.10/node-v0.6.10.pkg</a></p> |
|||
|
|||
<p>Website: <a href="http://nodejs.org/docs/v0.6.10/">http://nodejs.org/docs/v0.6.10/</a></p> |
|||
|
|||
<p>Documentation: <a href="http://nodejs.org/docs/v0.6.10/api/">http://nodejs.org/docs/v0.6.10/api/</a></p> |
|||
@ -1,27 +0,0 @@ |
|||
version: 0.6.2 |
|||
title: Node v0.6.2 |
|||
author: bennoordhuis |
|||
date: Fri Nov 18 2011 15:35:32 GMT-0800 (PST) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-6-2 |
|||
|
|||
<p>2011.11.18, Version 0.6.2 (stable)</p> |
|||
<ul> |
|||
<li>doc improvements (Artur Adib, Trevor Burnham, Ryan Emery, Trent Mick)</li> |
|||
<li>timers: remember extra setTimeout() arguments when timeout==0</li> |
|||
<li>punycode: use Mathias Bynens's punycode library, it's more compliant</li> |
|||
<li>repl: improved tab completion (Ryan Emery)</li> |
|||
<li>buffer: fix range checks in .writeInt() functions (Lukasz Walukiewicz)</li> |
|||
<li>tls: make cipher list configurable</li> |
|||
<li>addons: make Buffer and ObjectWrap visible to Windows add-ons (Bert Belder)</li> |
|||
<li>crypto: add PKCS#1 a.k.a RSA public key verification support</li> |
|||
<li>windows: fix stdout writes when redirected to nul</li> |
|||
<li>sunos: fix build on Solaris and Illumos</li> |
|||
<li>Upgrade V8 to 3.6.6.8</li> |
|||
</ul> |
|||
<p>Source Code: <a href="http://nodejs.org/dist/v0.6.2/node-v0.6.2.tar.gz">http://nodejs.org/dist/v0.6.2/node-v0.6.2.tar.gz</a></p> |
|||
<p>Windows Installer: <a href="http://nodejs.org/dist/v0.6.2/node-v0.6.2.msi">http://nodejs.org/dist/v0.6.2/node-v0.6.2.msi</a></p> |
|||
<p>Macintosh Installer: <a href="http://nodejs.org/dist/v0.6.2/node-v0.6.2.pkg">http://nodejs.org/dist/v0.6.2/node-v0.6.2.pkg</a></p> |
|||
<p>Website: <a href="http://nodejs.org/docs/v0.6.2/">http://nodejs.org/docs/v0.6.2/</a></p> |
|||
<p>Documentation: <a href="http://nodejs.org/docs/v0.6.2/api/">http://nodejs.org/docs/v0.6.2/api/</a></p> |
|||
@ -1,30 +0,0 @@ |
|||
version: 0.6.3 |
|||
title: Node v0.6.3 |
|||
author: piscisaureus |
|||
date: Fri Nov 25 2011 02:54:08 GMT-0800 (PST) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-6-3 |
|||
|
|||
2011.11.25, Version 0.6.3 (stable) |
|||
<ul> |
|||
<li>#2083 Land NPM in Node. It is included in packages/installers and installed on `make install`.</li> |
|||
<li>#2076 Add logos to windows installer.</li> |
|||
<li>#1711 Correctly handle http requests without headers. (Ben Noordhuis, Felix Geisendörfer)</li> |
|||
<li>TLS: expose more openssl SSL context options and constants. (Ben Noordhuis)</li> |
|||
<li>#2177 Windows: don't kill UDP socket when a packet fails to reach its destination. (Bert Belder)</li> |
|||
<li>Windows: support paths longer than 260 characters. (Igor Zinkovsky)</li> |
|||
<li>Windows: correctly resolve drive-relative paths. (Bert Belder)</li> |
|||
<li>#2166 Don't leave file descriptor open after lchmod. (Isaac Schlueter)</li> |
|||
<li>#2084 Add OS X .pkg build script to make file.</li> |
|||
<li>#2160 Documentation improvements. (Ben Noordhuis)</li> |
|||
</ul> |
|||
Source Code: <a href="http://nodejs.org/dist/v0.6.3/node-v0.6.3.tar.gz">http://nodejs.org/dist/v0.6.3/node-v0.6.3.tar.gz</a> |
|||
|
|||
Windows Installer: <a href="http://nodejs.org/dist/v0.6.3/node-v0.6.3.msi">http://nodejs.org/dist/v0.6.3/node-v0.6.3.msi</a> |
|||
|
|||
Macintosh Installer: <a href="http://nodejs.org/dist/v0.6.3/node-v0.6.3.pkg">http://nodejs.org/dist/v0.6.3/node-v0.6.3.pkg</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.6.3/">http://nodejs.org/docs/v0.6.3/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.6.3/api/">http://nodejs.org/docs/v0.6.3/api/</a> |
|||
@ -1,31 +0,0 @@ |
|||
version: 0.6.4 |
|||
title: Node v0.6.4 |
|||
author: bennoordhuis |
|||
date: Thu Dec 01 2011 18:20:14 GMT-0800 (PST) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-6-4 |
|||
|
|||
2011.12.02, Version 0.6.4 (stable) |
|||
<ul> |
|||
<li>doc improvements (Kyle Young, Tim Oxley, Roman Shtylman, Mathias Bynens)</li> |
|||
<li>upgrade bundled npm (Isaac Schlueter)</li> |
|||
<li>polish Windows installer (Igor Zinkovsky, Isaac Schlueter)</li> |
|||
<li>punycode: upgrade to v0.2.1 (Mathias Bynens)</li> |
|||
<li>build: add --without-npm flag to configure script</li> |
|||
<li>sys: deprecate module some more, print stack trace if NODE_DEBUG=sys</li> |
|||
<li>cli: add -p switch, prints result of --eval</li> |
|||
<li>#1997: fix Blowfish ECB encryption and decryption (Ingmar Runge)</li> |
|||
<li>#2223: fix socket 'close' event being emitted twice</li> |
|||
<li>#2224: fix RSS memory usage > 4 GB reporting (Russ Bradberry)</li> |
|||
<li>#2225: fix util.inspect() object stringification bug (Nathan Rajlich)</li> |
|||
</ul> |
|||
Source Code: <a href="http://nodejs.org/dist/v0.6.4/node-v0.6.4.tar.gz">http://nodejs.org/dist/v0.6.4/node-v0.6.4.tar.gz</a> |
|||
|
|||
Windows Installer: <a href="http://nodejs.org/dist/v0.6.4/node-v0.6.4.msi">http://nodejs.org/dist/v0.6.4/node-v0.6.4.msi</a> |
|||
|
|||
Macintosh Installer: <a href="http://nodejs.org/dist/v0.6.4/node-v0.6.4.pkg">http://nodejs.org/dist/v0.6.4/node-v0.6.4.pkg</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.6.4/">http://nodejs.org/docs/v0.6.4/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.6.4/api/">http://nodejs.org/docs/v0.6.4/api/</a> |
|||
@ -1,21 +0,0 @@ |
|||
version: 0.6.5 |
|||
title: Node v0.6.5 |
|||
author: ryandahl |
|||
date: Sun Dec 04 2011 00:59:57 GMT-0800 (PST) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-6-5 |
|||
|
|||
2011.12.04, Version 0.6.5 (stable) |
|||
<ul><li>npm workaround Windows antivirus software (isaacs) |
|||
<li>Upgrade V8 to 3.6.6.11</ul> |
|||
|
|||
Source Code: <a href="http://nodejs.org/dist/v0.6.5/node-v0.6.5.tar.gz">http://nodejs.org/dist/v0.6.5/node-v0.6.5.tar.gz</a> |
|||
|
|||
Windows Installer: <a href="http://nodejs.org/dist/v0.6.5/node-v0.6.5.msi">http://nodejs.org/dist/v0.6.5/node-v0.6.5.msi</a> |
|||
|
|||
Macintosh Installer: <a href="http://nodejs.org/dist/v0.6.5/node-v0.6.5.pkg">http://nodejs.org/dist/v0.6.5/node-v0.6.5.pkg</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.6.5/">http://nodejs.org/docs/v0.6.5/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.6.5/api/">http://nodejs.org/docs/v0.6.5/api/</a> |
|||
@ -1,32 +0,0 @@ |
|||
version: 0.6.6 |
|||
title: Node v0.6.6 |
|||
author: Isaac Schlueter |
|||
date: Thu Dec 15 2011 11:07:57 GMT-0800 (PST) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-6-6 |
|||
|
|||
2011.12.14, Version 0.6.6 (stable) |
|||
|
|||
<ul> |
|||
<li>npm update to 1.1.0-beta-4 (Isaac Z. Schlueter)</li> |
|||
<li>cli: fix output of --help (Ben Noordhuis)</li> |
|||
<li>new website</li> |
|||
<li>pause/resume semantics for stdin (Isaac Z. Schlueter)</li> |
|||
<li>Travis CI integration (Maciej Małecki)</li> |
|||
<li>child_process: Fix bug regarding closed stdin (Ben Noordhuis)</li> |
|||
<li>Enable upgrades in MSI. (Igor Zinkovsky)</li> |
|||
<li>net: Fixes memory leak (Ben Noordhuis)</li> |
|||
<li>fs: handle fractional or NaN ReadStream buffer size (Ben Noordhuis)</li> |
|||
<li>crypto: fix memory leaks in PBKDF2 error path (Ben Noordhuis)</li> |
|||
</ul> |
|||
|
|||
Source Code: <a href="http://nodejs.org/dist/v0.6.6/node-v0.6.6.tar.gz">http://nodejs.org/dist/v0.6.6/node-v0.6.6.tar.gz</a> |
|||
|
|||
Windows Installer: <a href="http://nodejs.org/dist/v0.6.6/node-v0.6.6.msi">http://nodejs.org/dist/v0.6.6/node-v0.6.6.msi</a> |
|||
|
|||
Macintosh Installer: <a href="http://nodejs.org/dist/v0.6.6/node-v0.6.6.pkg">http://nodejs.org/dist/v0.6.6/node-v0.6.6.pkg</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.6.6/">http://nodejs.org/docs/v0.6.6/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.6.6/api/">http://nodejs.org/docs/v0.6.6/api/</a> |
|||
@ -1,41 +0,0 @@ |
|||
version: 0.6.7 |
|||
title: Node v0.6.7 |
|||
author: Isaac Schlueter |
|||
date: Fri Jan 06 2012 17:54:49 GMT-0800 (PST) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-6-7 |
|||
|
|||
<p>2012.01.06, Version 0.6.7 (stable)</p> |
|||
|
|||
<ul> |
|||
<li><p>V8 hash collision fix (Breaks MIPS) (Bert Belder, Erik Corry)</p></li> |
|||
<li><p>Upgrade V8 to 3.6.6.15</p></li> |
|||
<li><p>Upgrade npm to 1.1.0-beta-10 (isaacs)</p></li> |
|||
<li><p>many doc updates (Ben Noordhuis, Jeremy Martin, koichik, Dave Irvine, |
|||
Seong-Rak Choi, Shannen, Adam Malcontenti-Wilson, koichik)</p></li> |
|||
<li><p>Fix segfault in <code>node_http_parser.cc</code></p></li> |
|||
<li><p>dgram, timers: fix memory leaks (Ben Noordhuis, Yoshihiro Kikuchi)</p></li> |
|||
<li><p>repl: fix repl.start not passing the <code>ignoreUndefined</code> arg (Damon Oehlman)</p></li> |
|||
<li><p>#1980: Socket.pause null reference when called on a closed Stream (koichik)</p></li> |
|||
<li><p>#2263: XMLHttpRequest piped in a writable file stream hang (koichik)</p></li> |
|||
<li><p>#2069: http resource leak (koichik)</p></li> |
|||
<li><p>buffer.readInt global pollution fix (Phil Sung)</p></li> |
|||
<li><p>timers: fix performance regression (Ben Noordhuis)</p></li> |
|||
<li><p>#2308, #2246: node swallows openssl error on request (koichik)</p></li> |
|||
<li><p>#2114: timers: remove _idleTimeout from item in .unenroll() (James Hartig)</p></li> |
|||
<li><p>#2379: debugger: Request backtrace w/o refs (Fedor Indutny)</p></li> |
|||
<li><p>simple DTrace ustack helper (Dave Pacheco)</p></li> |
|||
<li><p>crypto: rewrite HexDecode without snprintf (Roman Shtylman)</p></li> |
|||
<li><p>crypto: don’t ignore DH init errors (Ben Noordhuis)</p></li> |
|||
</ul> |
|||
|
|||
<p>Source Code: <a href="http://nodejs.org/dist/v0.6.7/node-v0.6.7.tar.gz">http://nodejs.org/dist/v0.6.7/node-v0.6.7.tar.gz</a></p> |
|||
|
|||
<p>Windows Installer: <a href="http://nodejs.org/dist/v0.6.7/node-v0.6.7.msi">http://nodejs.org/dist/v0.6.7/node-v0.6.7.msi</a></p> |
|||
|
|||
<p>Macintosh Installer: <a href="http://nodejs.org/dist/v0.6.7/node-v0.6.7.pkg">http://nodejs.org/dist/v0.6.7/node-v0.6.7.pkg</a></p> |
|||
|
|||
<p>Website: <a href="http://nodejs.org/docs/v0.6.7/">http://nodejs.org/docs/v0.6.7/</a></p> |
|||
|
|||
<p>Documentation: <a href="http://nodejs.org/docs/v0.6.7/api/">http://nodejs.org/docs/v0.6.7/api/</a></p> |
|||
@ -1,31 +0,0 @@ |
|||
version: 0.6.8 |
|||
title: Node v0.6.8 |
|||
author: Isaac Schlueter |
|||
date: Thu Jan 19 2012 19:59:53 GMT-0800 (PST) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-6-8 |
|||
|
|||
<p>2012.01.19, Version 0.6.8 (stable)</p> |
|||
|
|||
<ul> |
|||
<li><p>Update V8 to 3.6.6.19</p></li> |
|||
<li><p>Numeric key hash collision fix for V8 (Erik Corry, Fedor Indutny)</p></li> |
|||
<li><p>Add missing TTY key translations for F1-F5 on Windows (Brandon Benvie)</p></li> |
|||
<li><p>path.extname bugfix with . and .. paths (Bert Belder)</p></li> |
|||
<li><p>cluster: don't always kill the master on uncaughtException (Ben Noordhuis)</p></li> |
|||
<li><p>Update npm to 1.1.0-2 (isaacs)</p></li> |
|||
<li><p>typed arrays: set class name (Ben Noordhuis)</p></li> |
|||
<li><p>zlib binding cleanup (isaacs, Bert Belder)</p></li> |
|||
<li><p>dgram: use slab memory allocator (Michael Bernstein)</p></li> |
|||
<li><p>fix segfault #2473</p></li> |
|||
<li><p>#2521 60% improvement in fs.stat on Windows (Igor Zinkovsky)</p></li> |
|||
</ul><p>Source Code: <a href="http://nodejs.org/dist/v0.6.8/node-v0.6.8.tar.gz">http://nodejs.org/dist/v0.6.8/node-v0.6.8.tar.gz</a></p> |
|||
|
|||
<p>Windows Installer: <a href="http://nodejs.org/dist/v0.6.8/node-v0.6.8.msi">http://nodejs.org/dist/v0.6.8/node-v0.6.8.msi</a></p> |
|||
|
|||
<p>Macintosh Installer: <a href="http://nodejs.org/dist/v0.6.8/node-v0.6.8.pkg">http://nodejs.org/dist/v0.6.8/node-v0.6.8.pkg</a></p> |
|||
|
|||
<p>Website: <a href="http://nodejs.org/docs/v0.6.8/">http://nodejs.org/docs/v0.6.8/</a></p> |
|||
|
|||
<p>Documentation: <a href="http://nodejs.org/docs/v0.6.8/api/">http://nodejs.org/docs/v0.6.8/api/</a></p> |
|||
@ -1,30 +0,0 @@ |
|||
version: 0.6.9 |
|||
title: Node v0.6.9 |
|||
author: Isaac Schlueter |
|||
date: Fri Jan 27 2012 16:58:18 GMT-0800 (PST) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-6-9 |
|||
|
|||
<p>2012.01.27, Version 0.6.9 (stable)</p> |
|||
|
|||
<ul> |
|||
<li> |
|||
<p>dgram: Bring back missing functionality for Unix (Dan VerWeire, |
|||
Roman Shtylman, Ben Noordhuis)</p> |
|||
<p>- Note: Windows UDP support not yet complete.</p></li> |
|||
<li><p>http: Fix parser memory leak (koichik)</p></li> |
|||
<li><p>zlib: Fix #2365 crashes on invalid input (Nicolas LaCasse)</p></li> |
|||
<li><p>module: fix --debug-brk on symlinked scripts (Fedor Indutny)</p></li> |
|||
<li><p>Documentation Restyling (Matthew Fitzsimmons)</p></li> |
|||
<li><p>Update npm to 1.1.0-3 (isaacs)</p></li> |
|||
<li><p>Windows: fix regression in stat() calls to C:\ (Bert Belder)</p></li> |
|||
</ul><p>Source Code: <a href="http://nodejs.org/dist/v0.6.9/node-v0.6.9.tar.gz">http://nodejs.org/dist/v0.6.9/node-v0.6.9.tar.gz</a></p> |
|||
|
|||
<p>Windows Installer: <a href="http://nodejs.org/dist/v0.6.9/node-v0.6.9.msi">http://nodejs.org/dist/v0.6.9/node-v0.6.9.msi</a></p> |
|||
|
|||
<p>Macintosh Installer: <a href="http://nodejs.org/dist/v0.6.9/node-v0.6.9.pkg">http://nodejs.org/dist/v0.6.9/node-v0.6.9.pkg</a></p> |
|||
|
|||
<p>Website: <a href="http://nodejs.org/docs/v0.6.9/">http://nodejs.org/docs/v0.6.9/</a></p> |
|||
|
|||
<p>Documentation: <a href="http://nodejs.org/docs/v0.6.9/api/">http://nodejs.org/docs/v0.6.9/api/</a></p> |
|||
@ -1,29 +0,0 @@ |
|||
version: 0.7.0 |
|||
title: Node v0.7.0 (Unstable) |
|||
author: ryandahl |
|||
date: Mon Jan 16 2012 19:58:28 GMT-0800 (PST) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-7-0-unstable |
|||
|
|||
<strong>This is the first release in the unstable v0.7 series. Almost all users will want to remain using the stable v0.6 releases.</strong> |
|||
|
|||
2012.01.16, Version 0.7.0 (unstable) |
|||
<ul> |
|||
<li>Upgrade V8 to 3.8.6 |
|||
<li>Use GYP build system on unix (Ben Noordhuis) |
|||
<li>Experimental isolates support (Ben Noordhuis) |
|||
<li>Improvements to Cluster API (Andreas Madsen) |
|||
<li>Use isolates for internal debugger (Fedor Indutny) |
|||
<li>Bug fixes</ul> |
|||
|
|||
|
|||
Source Code: <a href="http://nodejs.org/dist/v0.7.0/node-v0.7.0.tar.gz">http://nodejs.org/dist/v0.7.0/node-v0.7.0.tar.gz</a> |
|||
|
|||
Windows Installer: <a href="http://nodejs.org/dist/v0.7.0/node-v0.7.0.msi">http://nodejs.org/dist/v0.7.0/node-v0.7.0.msi</a> |
|||
|
|||
Macintosh Installer: <a href="http://nodejs.org/dist/v0.7.0/node-v0.7.0.pkg">http://nodejs.org/dist/v0.7.0/node-v0.7.0.pkg</a> |
|||
|
|||
Website: <a href="http://nodejs.org/docs/v0.7.0/">http://nodejs.org/docs/v0.7.0/</a> |
|||
|
|||
Documentation: <a href="http://nodejs.org/docs/v0.7.0/api/">http://nodejs.org/docs/v0.7.0/api/</a> |
|||
@ -1,30 +0,0 @@ |
|||
version: 0.7.1 |
|||
title: Node v0.7.1 |
|||
author: Isaac Schlueter |
|||
date: Mon Jan 23 2012 17:35:59 GMT-0800 (PST) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-7-1 |
|||
|
|||
<p>2012.01.23, Version 0.7.1 (unstable)</p> |
|||
|
|||
<ul> |
|||
<li><p>Update V8 to 3.8.8</p></li> |
|||
<li><p>Install node-waf by default (Fedor Indutny)</p></li> |
|||
<li><p>crypto: Add ability to turn off PKCS padding (Ingmar Runge)</p></li> |
|||
<li><p>v8: implement VirtualMemory class on SunOS (Ben Noordhuis)</p></li> |
|||
<li><p>Add cluster.setupMaster (Andreas Madsen)</p></li> |
|||
<li><p>move <code>path.exists*</code> to <code>fs.exists*</code> (Maciej Małecki)</p></li> |
|||
<li><p>typed arrays: set class name (Ben Noordhuis)</p></li> |
|||
<li><p>libuv bug fixes (Igor Zinkovsky, Ben Noordhuis, Dan VerWeire)</p></li> |
|||
</ul> |
|||
|
|||
<p>Source: <a href="http://nodejs.org/dist/v0.7.1/node-v0.7.1.tar.gz">http://nodejs.org/dist/v0.7.1/node-v0.7.1.tar.gz</a></p> |
|||
|
|||
<p>Windows Installer: <a href="http://nodejs.org/dist/v0.7.1/node-v0.7.1.msi">http://nodejs.org/dist/v0.7.1/node-v0.7.1.msi</a></p> |
|||
|
|||
<p>Macintosh Installer: <a href="http://nodejs.org/dist/v0.7.1/node-v0.7.1.pkg">http://nodejs.org/dist/v0.7.1/node-v0.7.1.pkg</a></p> |
|||
|
|||
<p>Website: <a href="http://nodejs.org/docs/v0.7.1/">http://nodejs.org/docs/v0.7.1/</a></p> |
|||
|
|||
<p>Documentation: <a href="http://nodejs.org/docs/v0.7.1/api/">http://nodejs.org/docs/v0.7.1/api/</a></p> |
|||
@ -1,32 +0,0 @@ |
|||
version: 0.7.2 |
|||
title: Node v0.7.2 (unstable) |
|||
author: Isaac Schlueter |
|||
date: Wed Feb 01 2012 13:13:04 GMT-0800 (PST) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-7-2-unstable |
|||
|
|||
<p>2012.02.01, Version 0.7.2 (unstable)</p> |
|||
|
|||
<ul> |
|||
<li><p>Update V8 to 3.8.9</p></li> |
|||
<li><p>Support for sharing streams across Isolates (Igor Zinkovsky)</p></li> |
|||
<li><p>#2636 - Fix case where http_parsers are freed too early (koichik)</p></li> |
|||
<li><p>url: Support for IPv6 addresses in URLs (Łukasz Walukiewicz)</p></li> |
|||
<li><p>child_process: Add disconnect() method to child processes (Andreas Madsen)</p></li> |
|||
<li><p>fs: add O_EXCL support, exclusive open file (Ben Noordhuis)</p></li> |
|||
<li><p>fs: more specific error messages (Tj Holowaychuk)</p></li> |
|||
<li><p>tty: emit 'unknown' key event if key sequence not found (Dan VerWeire, Nathan Rajlich)</p></li> |
|||
<li><p>build: compile release build too if BUILDTYPE=Debug (Ben Noordhuis)</p></li> |
|||
<li><p>module: fix --debug-brk on symlinked scripts (Fedor Indutny)</p></li> |
|||
<li><p>zlib: fix <code>Failed to set dictionary</code> issue (Fedor Indutny)</p></li> |
|||
<li><p>waf: predict target arch for OS X (Fedor Indutny)</p></li> |
|||
</ul><p>Source Code: <a href="http://nodejs.org/dist/v0.7.2/node-v0.7.2.tar.gz">http://nodejs.org/dist/v0.7.2/node-v0.7.2.tar.gz</a></p> |
|||
|
|||
<p>Windows Installer: <a href="http://nodejs.org/dist/v0.7.2/node-v0.7.2.msi">http://nodejs.org/dist/v0.7.2/node-v0.7.2.msi</a></p> |
|||
|
|||
<p>Macintosh Installer: <a href="http://nodejs.org/dist/v0.7.2/node-v0.7.2.pkg">http://nodejs.org/dist/v0.7.2/node-v0.7.2.pkg</a></p> |
|||
|
|||
<p>Website: <a href="http://nodejs.org/docs/v0.7.2/">http://nodejs.org/docs/v0.7.2/</a></p> |
|||
|
|||
<p>Documentation: <a href="http://nodejs.org/docs/v0.7.2/api/">http://nodejs.org/docs/v0.7.2/api/</a></p> |
|||
@ -1,39 +0,0 @@ |
|||
version: 0.7.3 |
|||
title: Node v0.7.3 (unstable) |
|||
author: Isaac Schlueter |
|||
date: Tue Feb 07 2012 17:08:27 GMT-0800 (PST) |
|||
status: publish |
|||
category: release |
|||
slug: node-v0-7-3 |
|||
|
|||
<p>2012.02.07, Version 0.7.3 (unstable) |
|||
|
|||
</p> |
|||
<ul> |
|||
<li><p>Upgrade V8 to 3.9.2</p> |
|||
</li> |
|||
<li><p>Revert support for isolates. (Ben Noordhuis)</p> |
|||
</li> |
|||
<li><p>cluster: Cleanup docs, event handling, and process.disconnect (Andreas Madsen)</p> |
|||
</li> |
|||
<li><p>gyp_addon: link with node.lib on Windows (Nathan Rajlich)</p> |
|||
</li> |
|||
<li><p>http: fix case where http-parser is freed twice (koichik)</p> |
|||
</li> |
|||
<li><p>Windows: disable RTTI and exceptions (Bert Belder)</p> |
|||
</li> |
|||
</ul> |
|||
<p>Source Code: <a href="http://nodejs.org/dist/v0.7.3/node-v0.7.3.tar.gz">http://nodejs.org/dist/v0.7.3/node-v0.7.3.tar.gz</a> |
|||
|
|||
</p> |
|||
<p>Windows Installer: <a href="http://nodejs.org/dist/v0.7.3/node-v0.7.3.msi">http://nodejs.org/dist/v0.7.3/node-v0.7.3.msi</a> |
|||
|
|||
</p> |
|||
<p>Macintosh Installer: <a href="http://nodejs.org/dist/v0.7.3/node-v0.7.3.pkg">http://nodejs.org/dist/v0.7.3/node-v0.7.3.pkg</a> |
|||
|
|||
</p> |
|||
<p>Website: <a href="http://nodejs.org/docs/v0.7.3/">http://nodejs.org/docs/v0.7.3/</a> |
|||
|
|||
</p> |
|||
<p>Documentation: <a href="http://nodejs.org/docs/v0.7.3/api/">http://nodejs.org/docs/v0.7.3/api/</a> |
|||
</p> |
|||
@ -1,384 +0,0 @@ |
|||
title: Node v0.8.0 |
|||
date: Mon Jun 25 2012 09:00:00 GMT-0700 (PDT) |
|||
version: 0.8.0 |
|||
category: release |
|||
author: Isaac Z. Schlueter |
|||
slug: node-v0-8-0 |
|||
status: publish |
|||
|
|||
I am thrilled to announce the arrival of a new stable version of |
|||
Node.js. |
|||
|
|||
Compared with the v0.6 releases of Node, this release brings significant |
|||
improvements in many key performance metrics, as well as |
|||
cleanup in several core APIs, and the addition of new debugging |
|||
features. |
|||
|
|||
## tl;dr |
|||
|
|||
With version 0.8.0: |
|||
|
|||
1. Node got a lot faster. |
|||
2. Node got more stable. |
|||
3. You can do stuff with file descriptors again. |
|||
4. The [cluster module](http://nodejs.org/api/cluster.html) is much more |
|||
awesome. |
|||
5. The [domain module](http://nodejs.org/api/domain.html) was added. |
|||
6. The repl is better. |
|||
7. The build system changed from waf to gyp. |
|||
8. [Some other stuff changed, |
|||
too.](https://github.com/joyent/node/wiki/API-changes-between-v0.6-and-v0.8) |
|||
9. Scroll to the bottom for the links to install it. |
|||
|
|||
## Performance |
|||
|
|||
This version brings a few key enhancements in V8 and libuv that result |
|||
in significantly improved throughput. |
|||
|
|||
All of these benchmarks were run on my OS X laptop, but the results are |
|||
typical of what we're seeing on SmartOS, Linux, and Windows. |
|||
|
|||
``` |
|||
# io.js |
|||
|
|||
# 0.6.19, writes |
|||
Wrote 1024 byte buffers: 19.428793471925395 mB/s |
|||
Wrote 4096 byte buffers: 59.737156511350065 mB/s |
|||
Wrote 16384 byte buffers: 83.97010664203543 mB/s |
|||
Wrote 65536 byte buffers: 97.4184120798831 mB/s |
|||
|
|||
# 0.8.0, writes |
|||
Wrote 1024 byte buffers: 61.236987140232706 mB/s +215.19% |
|||
Wrote 4096 byte buffers: 109.05125408942203 mB/s +82.55% |
|||
Wrote 16384 byte buffers: 182.18254691200585 mB/s +116.96% |
|||
Wrote 65536 byte buffers: 181.91740949608877 mB/s +86.74% |
|||
|
|||
# v0.6.19, reads |
|||
Read 1024 byte buffers: 29.96883241428914 mB/s |
|||
Read 4096 byte buffers: 62.34413965087282 mB/s |
|||
Read 16384 byte buffers: 165.7550140891762 mB/s |
|||
Read 65536 byte buffers: 266.73779674579885 mB/s |
|||
|
|||
# v0.8.0, reads |
|||
Read 1024 byte buffers: 57.63688760806916 mB/s +92.32% |
|||
Read 4096 byte buffers: 136.7801942278758 mB/s +119.40% |
|||
Read 16384 byte buffers: 244.8579823702253 mB/s +47.72% |
|||
Read 65536 byte buffers: 302.2974607013301 mB/s +13.33% |
|||
``` |
|||
|
|||
The difference is not small. If you are writing network programs with |
|||
node, and pushing a lot of traffic, you will notice this improvement. |
|||
|
|||
The speed of reading files got quite a bit faster as well: |
|||
|
|||
``` |
|||
# v0.6.19 |
|||
read the file 110948 times (higher is better) |
|||
90141.32 ns per read (lower is better) |
|||
11093.69 reads per sec (higher is better) |
|||
|
|||
# v0.8.0 |
|||
read the file 158193 times (higher is better) +42.58% |
|||
63217.16 ns per read (lower is better) -29.87% |
|||
15818.48 reads per sec (higher is better) +42.59% |
|||
``` |
|||
|
|||
And of course, the ubiquitous 'hello, world' http server benchmark got |
|||
significantly faster, especially for large message sizes: |
|||
|
|||
``` |
|||
$ TYPE=bytes LENGTH=123 bash benchmark/http.sh 2>&1 | grep Req |
|||
# 0.6.19 |
|||
Requests per second: 3317.24 [#/sec] (mean) |
|||
# 0.8.0 |
|||
Requests per second: 3795.34 [#/sec] (mean) +14.41% |
|||
|
|||
|
|||
$ TYPE=bytes LENGTH=1024 bash benchmark/http.sh 2>&1 | grep Req |
|||
# v0.6.19 |
|||
Requests per second: 3258.42 [#/sec] (mean) |
|||
# 0.8.0 |
|||
Requests per second: 3585.62 [#/sec] (mean) +10.04% |
|||
|
|||
|
|||
$ TYPE=bytes LENGTH=123456 bash benchmark/http.sh 2>&1 | grep Req |
|||
# v0.6.19 |
|||
Requests per second: 218.51 [#/sec] (mean) |
|||
# 0.8.0 |
|||
Requests per second: 749.17 [#/sec] (mean) +242.85% |
|||
``` |
|||
|
|||
The difference with Unicode responses is even more pronounced: |
|||
|
|||
``` |
|||
$ TYPE=unicode LENGTH=1024 bash benchmark/http.sh 2>&1 | grep Req |
|||
# v0.6.19 |
|||
Requests per second: 3228.23 [#/sec] (mean) |
|||
# v0.8.0 |
|||
Requests per second: 3317.60 [#/sec] (mean) +2.77% |
|||
|
|||
$ TYPE=unicode LENGTH=12345 bash benchmark/http.sh 2>&1 | grep Req |
|||
# v0.6.19 |
|||
Requests per second: 1703.96 [#/sec] (mean) |
|||
# v0.8.0 |
|||
Requests per second: 2431.61 [#/sec] (mean) +42.70% |
|||
|
|||
$ TYPE=unicode LENGTH=55555 bash benchmark/http.sh 2>&1 | grep Req |
|||
#v0.6.19 |
|||
Requests per second: 161.65 [#/sec] (mean) |
|||
#v0.8.0 |
|||
Requests per second: 980.38 [#/sec] (mean) +506.48% |
|||
|
|||
$ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep Req |
|||
# v0.6.19 |
|||
^C # lost patience after a few hours |
|||
# v0.8.0 |
|||
Requests per second: 252.69 [#/sec] (mean) |
|||
``` |
|||
|
|||
The more bytes you're pushing, and the more work you're doing, the more |
|||
win you'll see with node 0.8 over 0.6. |
|||
|
|||
The vast majority of the performance boost is due to improvements in V8. |
|||
They've been very responsive to the needs of the Node.js project. A lot |
|||
of Node's success is due to being built on such a stellar VM. |
|||
|
|||
|
|||
## Build System |
|||
|
|||
Since its inception Node has used the WAF build system which is a Python |
|||
based system similar to SCons. The Chrome project recently changed to |
|||
the GYP meta-build system from SCons. GYP generates Makefiles, Visual |
|||
Studio project files, or XCode files depending on the target. V8, being |
|||
part of the Chrome project, now defines its build in GYP. By using GYP, |
|||
Node is able to: |
|||
|
|||
- integrate with the optimal build system on all platforms, |
|||
- easily able to integrate V8's build process into its own, and |
|||
- define its compilation declaratively for better manageability |
|||
|
|||
GYP was used already in Node v0.6 to build on Windows, but now it |
|||
defines the build on all platforms. Node is still in the process of |
|||
migrating external addon modules to GYP, and node-gyp is included with |
|||
npm. In future releases, node-waf will be officially deprecated. If |
|||
you are currently using a wscript in your addon, please migrate to gyp |
|||
as soon as possible. |
|||
|
|||
|
|||
## Stabler |
|||
|
|||
The transition from libev and libeio to libuv in 0.6 was somewhat |
|||
destabilizing for many node internals. The gambit paid off: libuv is |
|||
the obvious choice in cross-platform asynchronous IO libraries, and |
|||
Node.js is impressively performant on both Windows and Unix. But it |
|||
made the transition from 0.4 to 0.6 was very rocky for a lot of users. |
|||
Libuv wasn't as mature as node, and it showed in those early releases. |
|||
|
|||
At this point, with very few exceptions, if your v0.6 program doesn't |
|||
run on v0.8, it should be easy and obvious to make whatever changes are |
|||
necessary. Libuv has come a very long way, and Node 0.8 is a simpler |
|||
and more efficient machine as a result. |
|||
|
|||
See the [migration |
|||
wiki](https://github.com/joyent/node/wiki/API-changes-between-v0.6-and-v0.8) |
|||
for details on the specific APIs that changed. |
|||
|
|||
## The Return of File Descriptors |
|||
|
|||
In Node 0.4, there was a `listenFD` method that servers could use to |
|||
listen on a specific file descriptor that was already bound to a socket |
|||
or port. In 0.6, that functionality went away, largely because it was |
|||
very Unix-specific, and couldn't be easily made to work with the new |
|||
cross-platform libuv base. |
|||
|
|||
Since the most common use case for listenFD was as a method for having |
|||
servers in multiple node processes share the same underlying handle, the |
|||
`cluster` module was added in its place. However, this still left a lot |
|||
of use cases unaddressed, and was a reason why some people could not use |
|||
node 0.6 for their programs. |
|||
|
|||
In 0.8, we've replaced this functionality, as `server.listen({ fd: |
|||
number })`. |
|||
|
|||
The other feature in node 0.4 that got dropped in 0.6 was the ability to |
|||
pass arbitrary file descriptors as a child process's stdio, using the |
|||
`customFds` array. In Node 0.6, `customFds` could be used to inherit |
|||
the parent's stdio handles, but not to pass arbitrary handles or file |
|||
descriptors to the child's stdio. Also, there was never a way to pass |
|||
more than the standard `in, out, err` trio, so programs that expected |
|||
FD 4 to be opened in some specific way were out of luck. |
|||
|
|||
In 0.8, we've added the `stdio` array on the `child_process.spawn` |
|||
options. Pass as many file descriptors, handles, etc. as you like, and |
|||
the child process will see them as already-opened FDs. |
|||
|
|||
## More Powerful Cluster |
|||
|
|||
The cluster module in 0.8 is so much improved over 0.6, it's basically a |
|||
complete rewrite. The API is mostly backwards compatible, but not |
|||
entirely. (See the [migration |
|||
wiki](https://github.com/joyent/node/wiki/API-changes-between-v0.6-and-v0.8) |
|||
for details.) |
|||
|
|||
Barring these very minor API changes, if you were using cluster in 0.6, |
|||
then your program will still work, but it'll be faster and more |
|||
well-behaved now. And if you aren't taking advantage of the new |
|||
features in 0.8's cluster, you're really missing out. |
|||
|
|||
There's too much even to do it justice here. Go read [the API |
|||
docs](http://nodejs.org/api/cluster.html). |
|||
|
|||
## Domains |
|||
|
|||
The original idea for Domains was a way to join multiple different IO |
|||
actions, so that you can have some context when an error occurs. |
|||
|
|||
Since Ryan discussed the feature with node users at NodeConf Summer Camp |
|||
last year, the domains feature has gone through many revisions. The |
|||
problem is fairly well understood, but most attempts to solve it |
|||
resulted in serious performance regressions, or uncovered difficult edge |
|||
cases. |
|||
|
|||
What we ended up with in 0.8 is a very stripped-down version of this |
|||
idea. It's entirely opt-in, with minimal performance impact when it's |
|||
used (and none when it isn't). There are a lot of examples in [the API |
|||
documentation](http://nodejs.org/api/domain.html), so check them out, |
|||
and start handling your crashes smarter. |
|||
|
|||
The domain module is still experimental. We are looking forward to your |
|||
feedback, so please use it and let us know what you think. |
|||
|
|||
## Repl, Readline, TTY |
|||
|
|||
The Repl, Readline, and TTY modules have all had a major facelift. The |
|||
interfaces between these three modules are cleaned up and refactored, |
|||
removing a lot of common pain points and making it easier to use for |
|||
debugging your programs. |
|||
|
|||
It may seem minor at times, but a good repl dramatically increases the |
|||
quality of the overall experience. My personal favorites are: |
|||
|
|||
1. Typing `fs` or `net` or `path` will automatically load the module. |
|||
2. Typing `npm install ...` will give you a helpful message. |
|||
3. It doesn't do that stupid thing where long lines wrap and then the |
|||
backspace makes it get all confused and crazy. Instead of that, it |
|||
does the right thing. |
|||
|
|||
## Looking Forward |
|||
|
|||
Like other even-numbered version families before it, v0.8 will maintain |
|||
API and ABI stability throughout its lifetime. |
|||
|
|||
The v0.6 release family will continue to see releases for critical |
|||
bugfixes and security issues through the end of 2012. However, it will |
|||
not be the main focus of the core team's attention. |
|||
|
|||
The v0.9 releases will start in the next couple weeks. The main focus |
|||
of v0.9 will be: |
|||
|
|||
* The HTTP implementation - It has seen a lot of real-world use now, but |
|||
the http module is in dire need of a cleanup and refactor. Special |
|||
attention will be paid to making the interfaces more consistent, |
|||
improve performance, and increase correctness in more edge cases. |
|||
* The Streams API - The concept of the Stream API is very core to node. |
|||
However, it is also (like HTTP) a feature that grew up organically, |
|||
and is now in need of a cleanup. It is currently too hard to get |
|||
right, especially regarding error handling. |
|||
* Libuv Streams - The handle interfaces in libuv are going to be |
|||
refactored for added consistency throughout the codebase and across |
|||
platforms. |
|||
|
|||
Looking past that, there are a few areas where Node.js still has room |
|||
for improvement in terms of internal consistency, idiomatic JavaScript |
|||
usage, and performance. None of these are fully-fleshed out ideas yet, |
|||
but these are some of the items on our radar: |
|||
|
|||
* We ought to move to TypedArrays in favor of Buffers. Buffers will |
|||
continue to work, but since TypedArray is a JavaScript native, it |
|||
makes sense to move towards that as the preferred API. |
|||
* SSL performance leaves much to be desired at the moment. Node's |
|||
interface with OpenSSL is somewhat naive and leaves a lot of potential |
|||
optimization on the table. |
|||
* The VM module needs massive improvement. It lacks features required |
|||
to emulate a web browser JavaScript context, which means that it is |
|||
inadequate. |
|||
* The Crypto module still uses some very dated APIs. In 0.8, it can |
|||
accept Buffers for many things (finally!) but it still does not |
|||
present a Node-like streaming interface. |
|||
|
|||
At this point, the scope of Node's feature set is pretty much locked |
|||
down. We may move things around internally for these cleanup tasks, but |
|||
as you can see, there are no major new features planned. We've drawn |
|||
our boundaries, and now it's time to continue focusing on improving |
|||
stability and performance of the core, so that more innovation can |
|||
happen in **your** programs. |
|||
|
|||
And now, for those of you who may be wondering what was added since |
|||
v0.7.12, your regularly scheduled release announcement: |
|||
|
|||
## 2012.06.25, Version 0.8.0 (stable) |
|||
|
|||
* V8: upgrade to v3.11.10.10 |
|||
|
|||
* npm: Upgrade to 1.1.32 |
|||
|
|||
* Deprecate iowatcher (Ben Noordhuis) |
|||
|
|||
* windows: update icon (Bert Belder) |
|||
|
|||
* http: Hush 'MUST NOT have a body' warnings to debug() (isaacs) |
|||
|
|||
* Move blog.nodejs.org content into repository (isaacs) |
|||
|
|||
* Fix #3503: stdin: resume() on pipe(dest) (isaacs) |
|||
|
|||
* crypto: fix error reporting in SetKey() (Fedor Indutny) |
|||
|
|||
* Add --no-deprecation and --trace-deprecation command-line flags (isaacs) |
|||
|
|||
* fs: fix fs.watchFile() (Ben Noordhuis) |
|||
|
|||
* fs: Fix fs.readfile() on pipes (isaacs) |
|||
|
|||
* Rename GYP variable node_use_system_openssl to be consistent (Ryan Dahl) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.8.0/node-v0.8.0.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.8.0/node-v0.8.0.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.8.0/node-v0.8.0-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.8.0/x64/node-v0.8.0-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.8.0/x64/ |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.8.0/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.8.0/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.8.0/api/ |
|||
|
|||
Shasums: |
|||
|
|||
``` |
|||
b92208b291ad420025c65661a7df51fc618e21ca license.rtf |
|||
0786bcda79bd651b9981682527a1bbabe0250700 node-v0.8.0-x86.msi |
|||
8f160a742a01fdfc1b1423b3fc742d184f1ab70c node-v0.8.0-x86.wixpdb |
|||
6035d6d59304add21e462cd7eb89491570b4970d node-v0.8.0.pkg |
|||
5171fb46fbfee5ac7129c4b17207a3f35a1f57e8 node-v0.8.0.tar.gz |
|||
742100a4ee4cd4d190031a30d9b22b2b69b6872e node.exe |
|||
52d20d285e9aec53043af0843f5ecc4153210693 node.exp |
|||
6d67a64274d844548cc6099c76181a50feafc233 node.lib |
|||
aa2af08d5ab869e6c8b67f01ed67129c1cad8bce node.pdb |
|||
b92208b291ad420025c65661a7df51fc618e21ca x64/license.rtf |
|||
c4d4164d4f78ea68e0e2a85b96f9b355f3b1df8b x64/node-v0.8.0-x64.msi |
|||
df8bb178ee4cb9562d93fe80bbe59b2acf1b9e6b x64/node-v0.8.0-x64.wixpdb |
|||
fc07b475d943f7681e1904d6d7d666b41874a6fa x64/node.exe |
|||
895002806dfb6d5bb141ef0f43cad3b540a4ff6c x64/node.exp |
|||
686c60d5ae5dad7fcffcdc88049c63b2cd23cffc x64/node.lib |
|||
75549cffab0c11107348a66ab0d94d4897bd6a27 x64/node.pdb |
|||
``` |
|||
|
|||
<ins>Edited by Tim Oxley to provide percentage differences in the |
|||
benchmarks.</ins> |
|||
@ -1,61 +0,0 @@ |
|||
version: 0.6.19 |
|||
title: Node Version 0.6.19 (stable) |
|||
author: Isaac Schlueter |
|||
date: Wed Jun 06 2012 09:55:37 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-version-0-6-19-stable |
|||
|
|||
<p>2012.06.06 Version 0.6.19 (stable) |
|||
|
|||
</p> |
|||
<ul> |
|||
<li><p>npm: upgrade to 1.1.24</p> |
|||
</li> |
|||
<li><p>fs: no end emit after createReadStream.pause() (Andreas Madsen)</p> |
|||
</li> |
|||
<li><p>vm: cleanup module memory leakage (Marcel Laverdet)</p> |
|||
</li> |
|||
<li><p>unix: fix loop starvation under high network load (Ben Noordhuis)</p> |
|||
</li> |
|||
<li><p>unix: remove abort() in ev_unref() (Ben Noordhuis)</p> |
|||
</li> |
|||
<li><p>windows/tty: never report error after forcibly aborting line-buffered read (Bert Belder)</p> |
|||
</li> |
|||
<li><p>windows: skip GetFileAttributes call when opening a file (Bert Belder)</p> |
|||
</li> |
|||
</ul> |
|||
<p>Source Code: <a href="http://nodejs.org/dist/v0.6.19/node-v0.6.19.tar.gz">http://nodejs.org/dist/v0.6.19/node-v0.6.19.tar.gz</a> |
|||
|
|||
</p> |
|||
<p>Windows Installer: <a href="http://nodejs.org/dist/v0.6.19/node-v0.6.19.msi">http://nodejs.org/dist/v0.6.19/node-v0.6.19.msi</a> |
|||
|
|||
</p> |
|||
<p>Windows x64 Files: <a href="http://nodejs.org/dist/v0.6.19/x64/">http://nodejs.org/dist/v0.6.19/x64/</a> |
|||
|
|||
</p> |
|||
<p>Macintosh Installer (Universal): <a href="http://nodejs.org/dist/v0.6.19/node-v0.6.19.pkg">http://nodejs.org/dist/v0.6.19/node-v0.6.19.pkg</a> |
|||
|
|||
</p> |
|||
<p>Other release files: <a href="http://nodejs.org/dist/v0.6.19/">http://nodejs.org/dist/v0.6.19/</a> |
|||
|
|||
</p> |
|||
<p>Website: <a href="http://nodejs.org/docs/v0.6.19/">http://nodejs.org/docs/v0.6.19/</a> |
|||
|
|||
</p> |
|||
<p>Documentation: <a href="http://nodejs.org/docs/v0.6.19/api/">http://nodejs.org/docs/v0.6.19/api/</a> |
|||
</p> |
|||
|
|||
<p>Shasums:</p> |
|||
<pre>ef4f5c1e5f12f6ef3478a794d6a81f59669332f9 node-v0.6.19.msi |
|||
781616f33208f532f168633758a648c20e1ea68b node-v0.6.19.pkg |
|||
f6c5cfbadff4788ac3a95f8263a0c2f4e07444b6 node-v0.6.19.tar.gz |
|||
10f729ca236825821d97556441fa64f994cb4ca8 node.exe |
|||
5b8cd02e5f92ed6512aabdac11766ad8c1abc436 node.exp |
|||
20037e4901de605e08e48d0c85531334912844e3 node.lib |
|||
c44f62852918d449850014d9b29dd073cb6920a5 node.pdb |
|||
04db25c93c5357394941dd2de12cb61959eb82d1 x64/node-v0.6.19.msi |
|||
f77c77f2e470cfc9071853af2f277ba91d660b9c x64/node.exe |
|||
fcf26a3f984a3f19804e0567414604b77b1d3bac x64/node.exp |
|||
bfed2a24f253dbac99379d6f22fc8e9e85ade7ed x64/node.lib |
|||
95226c1cc5170ea05c2e54431040f06c3e95e99f x64/node.pdb</pre> |
|||
@ -1,73 +0,0 @@ |
|||
version: 0.7.9 |
|||
title: Node Version 0.7.9 (unstable) |
|||
author: Isaac Schlueter |
|||
date: Tue May 29 2012 10:11:45 GMT-0700 (PDT) |
|||
status: publish |
|||
category: release |
|||
slug: node-version-0-7-9-unstable |
|||
|
|||
<p>2012.05.28, Version 0.7.9 (unstable) |
|||
|
|||
</p> |
|||
<ul> |
|||
<li><p>Upgrade V8 to 3.11.1</p> |
|||
</li> |
|||
<li><p>Upgrade npm to 1.1.23</p> |
|||
</li> |
|||
<li><p>uv: rework reference counting scheme (Ben Noordhuis)</p> |
|||
</li> |
|||
<li><p>uv: add interface for joining external event loops (Bert Belder)</p> |
|||
</li> |
|||
<li><p>repl, readline: Handle Ctrl+Z and SIGCONT better (Nathan Rajlich)</p> |
|||
</li> |
|||
<li><p>fs: 64bit offsets for fs calls (Igor Zinkovsky)</p> |
|||
</li> |
|||
<li><p>fs: add sync open flags 'rs' and 'rs+' (Kevin Bowman)</p> |
|||
</li> |
|||
<li><p>windows: enable creating directory junctions with fs.symlink (Igor Zinkovsky, Bert Belder)</p> |
|||
</li> |
|||
<li><p>windows: fix fs.lstat to properly detect symlinks. (Igor Zinkovsky)</p> |
|||
</li> |
|||
<li><p>Fix #3270 Escape url.parse delims (isaacs)</p> |
|||
</li> |
|||
<li><p>http: make http.get() accept a URL (Adam Malcontenti-Wilson)</p> |
|||
</li> |
|||
<li><p>Cleanup vm module memory leakage (Marcel Laverdet)</p> |
|||
</li> |
|||
<li><p>Optimize writing strings with Socket.write (Bert Belder)</p> |
|||
</li> |
|||
<li><p>add support for CESU-8 and UTF-16LE encodings (koichik)</p> |
|||
</li> |
|||
<li><p>path: add path.sep to get the path separator. (Yi, EungJun)</p> |
|||
</li> |
|||
<li><p>net, http: add backlog parameter to .listen() (Erik Dubbelboer)</p> |
|||
</li> |
|||
<li><p>debugger: support mirroring Date objects (Fedor Indutny)</p> |
|||
</li> |
|||
<li><p>addon: add AtExit() function (Ben Noordhuis)</p> |
|||
</li> |
|||
<li><p>net: signal localAddress bind failure in connect (Brian Schroeder)</p> |
|||
</li> |
|||
<li><p>util: handle non-string return value in .inspect() (Alex Kocharin)</p> |
|||
</li> |
|||
</ul> |
|||
<p>Source Code: <a href="http://nodejs.org/dist/v0.7.9/node-v0.7.9.tar.gz">http://nodejs.org/dist/v0.7.9/node-v0.7.9.tar.gz</a> |
|||
|
|||
</p> |
|||
<p>Windows Installer: <a href="http://nodejs.org/dist/v0.7.9/node-v0.7.9.msi">http://nodejs.org/dist/v0.7.9/node-v0.7.9.msi</a> |
|||
|
|||
</p> |
|||
<p>Windows x64 Files: <a href="http://nodejs.org/dist/v0.7.9/x64/">http://nodejs.org/dist/v0.7.9/x64/</a> |
|||
|
|||
</p> |
|||
<p>Macintosh Installer (Universal): <a href="http://nodejs.org/dist/v0.7.9/node-v0.7.9.pkg">http://nodejs.org/dist/v0.7.9/node-v0.7.9.pkg</a> |
|||
|
|||
</p> |
|||
<p>Other release files: <a href="http://nodejs.org/dist/v0.7.9/">http://nodejs.org/dist/v0.7.9/</a> |
|||
|
|||
</p> |
|||
<p>Website: <a href="http://nodejs.org/docs/v0.7.9/">http://nodejs.org/docs/v0.7.9/</a> |
|||
|
|||
</p> |
|||
<p>Documentation: <a href="http://nodejs.org/docs/v0.7.9/api/">http://nodejs.org/docs/v0.7.9/api/</a> |
|||
</p> |
|||
@ -1,487 +0,0 @@ |
|||
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 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: |
|||
|
|||
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 |
|||
``` |
|||
@ -1,82 +0,0 @@ |
|||
date: Thu Mar 21 09:09:59 PDT 2013 |
|||
version: 0.10.1 |
|||
category: release |
|||
title: Node v0.10.1 (Stable) |
|||
slug: node-v0-10-1-stable |
|||
|
|||
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/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.1/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.1/api/ |
|||
|
|||
Shasums: |
|||
``` |
|||
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 |
|||
``` |
|||
@ -1,63 +0,0 @@ |
|||
date: Tue Jun 4 14:37:25 PDT 2013 |
|||
version: 0.10.10 |
|||
category: release |
|||
title: Node v0.10.10 (Stable) |
|||
slug: node-v0-10-10-stable |
|||
|
|||
2013.06.04, Version 0.10.10 (Stable) |
|||
|
|||
* uv: Upgrade to 0.10.10 |
|||
|
|||
* npm: Upgrade to 1.2.25 |
|||
|
|||
* url: Properly parse certain oddly formed urls (isaacs) |
|||
|
|||
* stream: unshift('') is a noop (isaacs) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.10/node-v0.10.10.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.10/node-v0.10.10.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.10/node-v0.10.10-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.10/x64/node-v0.10.10-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.10/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.10/node-v0.10.10-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.10/node-v0.10.10-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.10/node-v0.10.10-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.10/node-v0.10.10-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.10/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.10/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.10/api/ |
|||
|
|||
Shasums: |
|||
|
|||
``` |
|||
d632cad2adb5b4eef7a94bc9e549579586b381f5 node-v0.10.10-darwin-x64.tar.gz |
|||
6f74d0ca1a3bc810a4e73267451c0177be405874 node-v0.10.10-darwin-x86.tar.gz |
|||
b8a1f1954027b88b9545f3a2161543635f2120e7 node-v0.10.10-linux-x64.tar.gz |
|||
aae6893ee82cee09eec0351b770d4857e31e46b7 node-v0.10.10-linux-x86.tar.gz |
|||
0004745f5c0f96efc85f2bd9d9df24b1b706f77e node-v0.10.10-sunos-x64.tar.gz |
|||
a4e623f6688fde7f30d720ac4b1228546da823db node-v0.10.10-sunos-x86.tar.gz |
|||
1f09e829c92274de13270a7519e9e1cd5788e0a8 node-v0.10.10-x86.msi |
|||
24f7573e92060565ba84b7700efc4d9cf566e5ba node-v0.10.10.pkg |
|||
c21643a57b1ec9eca56e6deac22fe075616e0e9c node-v0.10.10.tar.gz |
|||
419fc85e5e16139260f7b2080ffbb66550fbe93f node.exe |
|||
bb2782228bf4f8783f9e6a9d1171f8ff0835c9b9 node.exp |
|||
28ce8d1f8156e6a8bf38844738f4a76499e0d2ce node.lib |
|||
eb58da2b123bc7aaceaa37a7a0bcc048d8d8dcc1 node.pdb |
|||
781f75fc1c7499edb8d7e247d774266d57514d21 x64/node-v0.10.10-x64.msi |
|||
14b75f31d14ca2e0fb90308e98a3567c6de0434e x64/node.exe |
|||
c5723e00cc875543ae263121d34d204690561860 x64/node.exp |
|||
df523e092ee9ff13b3acf4f4b574d043c0da6d9a x64/node.lib |
|||
db2a8874a3bc7cd21b8b29bc7faa5f75c8af0414 x64/node.pdb |
|||
``` |
|||
@ -1,70 +0,0 @@ |
|||
date: Thu Jun 13 11:34:24 PDT 2013 |
|||
version: 0.10.11 |
|||
category: release |
|||
title: Node v0.10.11 (Stable) |
|||
slug: node-v0-10-11-stable |
|||
|
|||
2013.06.13, Version 0.10.11 (Stable) |
|||
|
|||
* uv: upgrade to 0.10.11 |
|||
|
|||
* npm: Upgrade to 1.2.30 |
|||
|
|||
* openssl: add missing configuration pieces for MIPS (Andrei Sedoi) |
|||
|
|||
* Revert "http: remove bodyHead from 'upgrade' events" (isaacs) |
|||
|
|||
* v8: fix pointer arithmetic undefined behavior (Trevor Norris) |
|||
|
|||
* crypto: fix utf8/utf-8 encoding check (Ben Noordhuis) |
|||
|
|||
* net: Fix busy loop on POLLERR|POLLHUP on older linux kernels (Ben Noordhuis, isaacs) |
|||
|
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.11/node-v0.10.11.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.11/node-v0.10.11.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.11/node-v0.10.11-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.11/x64/node-v0.10.11-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.11/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.11/node-v0.10.11-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.11/node-v0.10.11-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.11/node-v0.10.11-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.11/node-v0.10.11-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.11/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.11/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.11/api/ |
|||
|
|||
Shasums: |
|||
|
|||
``` |
|||
c460678436e513ef5b8b8513abd74c75d8ebf7bb node-v0.10.11-darwin-x64.tar.gz |
|||
edd321fc6d7525774a12433e943db3a7817a19b9 node-v0.10.11-darwin-x86.tar.gz |
|||
1388e8a2b6b4b2043db4fc382959d43e7c32e28e node-v0.10.11-linux-x64.tar.gz |
|||
2923e08deeb08a5ce1a29607c00f8b8e4fbd16c8 node-v0.10.11-linux-x86.tar.gz |
|||
4d12e60a9bf4c9c418d88951733a6a51201b789d node-v0.10.11-sunos-x64.tar.gz |
|||
842e283ea724a6d69a17e18426c32e6fd4b0734b node-v0.10.11-sunos-x86.tar.gz |
|||
bbc874e7ad72d980a19ee76dc1d9012d801f1d8f node-v0.10.11-x86.msi |
|||
05d0a697a183f809a949832a0fd98e1e30d53e72 node-v0.10.11.pkg |
|||
4f646bb3418d1c177ce28cdbc61e71de35b38aea node-v0.10.11.tar.gz |
|||
e2eec3e170e1d26622231ee3f0b632485756a5f0 node.exe |
|||
8957dd0c31c115819f9387250f038a1e6259cfa9 node.exp |
|||
930ba687c31f09dd199c0cfb2ac492f57c0f640f node.lib |
|||
6bd963cff4baba07cb05d7e6aa566aebe8db5519 node.pdb |
|||
016356e656ac8091900637e3fb64ddc3dd53cfb5 x64/node-v0.10.11-x64.msi |
|||
a845f30c9f0100b6f4d79080c72068ff497c5c23 x64/node.exe |
|||
00719da33432ae9a264407c89239ce5a76e21df0 x64/node.exp |
|||
1f96e883134197c27aada23847b049491dd46b13 x64/node.lib |
|||
83989e612f56b0a8e90e4fad8cb1a7d8b0bdfcd0 x64/node.pdb |
|||
``` |
|||
@ -1,67 +0,0 @@ |
|||
date: Tue Jun 18 11:12:19 PDT 2013 |
|||
version: 0.10.12 |
|||
category: release |
|||
title: Node v0.10.12 (Stable) |
|||
slug: node-v0-10-12-stable |
|||
|
|||
2013.06.18, Version 0.10.12 (Stable) |
|||
|
|||
* npm: Upgrade to 1.2.32 |
|||
|
|||
* readline: make `ctrl + L` clear the screen (Yuan Chuan) |
|||
|
|||
* v8: add setVariableValue debugger command (Ben Noordhuis) |
|||
|
|||
* net: Do not destroy socket mid-write (isaacs) |
|||
|
|||
* v8: fix build for mips32r2 architecture (Andrei Sedoi) |
|||
|
|||
* configure: fix cross-compilation host_arch_cc() (Andrei Sedoi) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.12/node-v0.10.12.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.12/node-v0.10.12.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.12/node-v0.10.12-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.12/x64/node-v0.10.12-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.12/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.12/node-v0.10.12-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.12/node-v0.10.12-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.12/node-v0.10.12-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.12/node-v0.10.12-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.12/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.12/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.12/api/ |
|||
|
|||
Shasums: |
|||
|
|||
``` |
|||
e3c28629938d70dac535dca0b78199ae7e4e7cf6 node-v0.10.12-darwin-x64.tar.gz |
|||
d777c8c50270b7c834ee9ca95c186d30e181f885 node-v0.10.12-darwin-x86.tar.gz |
|||
c5b9cbb9b6329767f11a89c14e09afa795e3f9e9 node-v0.10.12-linux-x64.tar.gz |
|||
f7a7ac317ab3a8406ec11ec118c38971d5e4c508 node-v0.10.12-linux-x86.tar.gz |
|||
c5f446d6768298ad0d917f920f422a1e82d92fce node-v0.10.12-sunos-x64.tar.gz |
|||
05725a5255f762193838dac7175cbba418ef77c7 node-v0.10.12-sunos-x86.tar.gz |
|||
3403fed2cedf23764de50e17d0eeb5c960e88b79 node-v0.10.12-x86.msi |
|||
8e7cfecf737886014616d7c683bbb8a5ef38f4f7 node-v0.10.12.pkg |
|||
3e4f692fb9156c0cee4dd35bd8a6be4ff89a29de node-v0.10.12.tar.gz |
|||
d1cb17e753a5e0370c9ffe7f753e5c9b1d5bb9ff node.exe |
|||
af802e62b0da817543f5a4d51304d7fc49b4e56c node.exp |
|||
737eb43e0daed76112e8371f85176151dc380ac5 node.lib |
|||
b273075995dba44e7ae02641c3c8ba4c6301be8d node.pdb |
|||
e109532cc9d83599d7ebe18c325d14bdc7087ae8 x64/node-v0.10.12-x64.msi |
|||
1d902d66ecfd78c5bfef4181bab075119377006d x64/node.exe |
|||
3d79a1f3a94c31f73c095d9b3fd83ae80e14042f x64/node.exp |
|||
80295d8b0cb4922dbae01d85a0726f2721f0db00 x64/node.lib |
|||
2b5663f50946b13a1df4d9fcf7f9edd9605e130c x64/node.pdb |
|||
``` |
|||
@ -1,76 +0,0 @@ |
|||
date: Tue Jul 9 14:24:47 PDT 2013 |
|||
version: 0.10.13 |
|||
category: release |
|||
title: Node v0.10.13 (Stable) |
|||
slug: node-v0-10-13-stable |
|||
|
|||
2013.07.09, Version 0.10.13 (Stable) |
|||
|
|||
* uv: Upgrade to v0.10.12 |
|||
|
|||
* npm: Upgrade to 1.3.2 |
|||
|
|||
* windows: get proper errno (Ben Noordhuis) |
|||
|
|||
* tls: only wait for finish if we haven't seen it (Timothy J Fontaine) |
|||
|
|||
* http: Dump response when request is aborted (isaacs) |
|||
|
|||
* http: use an unref'd timer to fix delay in exit (Peter Rust) |
|||
|
|||
* zlib: level can be negative (Brian White) |
|||
|
|||
* zlib: allow zero values for level and strategy (Brian White) |
|||
|
|||
* buffer: add comment explaining buffer alignment (Ben Noordhuis) |
|||
|
|||
* string_bytes: properly detect 64bit (Timothy J Fontaine) |
|||
|
|||
* src: fix memory leak in UsingDomains() (Ben Noordhuis) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.13/node-v0.10.13.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.13/node-v0.10.13.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.13/node-v0.10.13-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.13/x64/node-v0.10.13-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.13/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.13/node-v0.10.13-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.13/node-v0.10.13-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.13/node-v0.10.13-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.13/node-v0.10.13-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.13/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.13/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.13/api/ |
|||
|
|||
Shasums: |
|||
``` |
|||
ae0b5d8e9afc57da259c7f30d266c968c16479bb node-v0.10.13-darwin-x64.tar.gz |
|||
5e5629a546f9aa2c1e11883021c416a6e0e12ad2 node-v0.10.13-darwin-x86.tar.gz |
|||
83b8f07aa7981694e557a9aae7e5bc4c312d800c node-v0.10.13-linux-x64.tar.gz |
|||
ec016d282d85036151dc096cd5cee6c8bd20fdd8 node-v0.10.13-linux-x86.tar.gz |
|||
3464241dc541bbf094ed11c0cd2ef8edb6419ee7 node-v0.10.13-sunos-x64.tar.gz |
|||
abca9f52cfac47cc0b3e92e3bc18b578a92915e6 node-v0.10.13-sunos-x86.tar.gz |
|||
5d020e9d3ef1021216e5cc294449c1a699b3f458 node-v0.10.13-x86.msi |
|||
841803a64e824f84361d4e7f6e1abd8ff31056ca node-v0.10.13.pkg |
|||
f73d5f134296ed0aa16cbec5d727f94587844155 node-v0.10.13.tar.gz |
|||
19beeb0f418b226a7ec7f15cdc0dccdf5f0d9e55 node.exe |
|||
eca52e8f39d4ac5bf3d07f6b50722f41b0494cc9 node.exp |
|||
2c47530c0d7c8e60f5c0daa78c105772b5638c9d node.lib |
|||
23c917f0c2c0e85677fb85583668b5e695315ced node.pdb |
|||
76cc14f56a3225e51f25b60faebe971cfb3ca322 x64/node-v0.10.13-x64.msi |
|||
e96c1687d447ed642ffd85134c0d949428a0b400 x64/node.exe |
|||
1962db68f17ffbd44c0ff82c0ff75b4ffe338319 x64/node.exp |
|||
95f162082c359d8610dd59ea634d4bd80d40c8aa x64/node.lib |
|||
3ec49f4849d5fdb3e1acbcff8e3eb02d9d55d332 x64/node.pdb |
|||
``` |
|||
@ -1,72 +0,0 @@ |
|||
date: Thu Jul 25 13:35:41 PDT 2013 |
|||
version: 0.10.14 |
|||
category: release |
|||
title: Node v0.10.14 (Stable) |
|||
slug: node-v0-10-14-stable |
|||
|
|||
2013.07.25, Version 0.10.14 (Stable) |
|||
|
|||
* uv: Upgrade to v0.10.13 |
|||
|
|||
* npm: Upgrade to v1.3.5 |
|||
|
|||
* os: Don't report negative times in cpu info (Ben Noordhuis) |
|||
|
|||
* fs: Handle large UID and GID (Ben Noordhuis) |
|||
|
|||
* url: Fix edge-case when protocol is non-lowercase (Shuan Wang) |
|||
|
|||
* doc: Streams API Doc Rewrite (isaacs) |
|||
|
|||
* node: call MakeDomainCallback in all domain cases (Trevor Norris) |
|||
|
|||
* crypto: fix memory leak in LoadPKCS12 (Fedor Indutny) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.14/node-v0.10.14.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.14/node-v0.10.14.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.14/node-v0.10.14-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.14/x64/node-v0.10.14-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.14/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.14/node-v0.10.14-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.14/node-v0.10.14-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.14/node-v0.10.14-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.14/node-v0.10.14-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.14/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.14/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.14/api/ |
|||
|
|||
Shasums: |
|||
``` |
|||
f6a13dc93f677e9d71f15570ea3db2244c09b26e node-v0.10.14-darwin-x64.tar.gz |
|||
c7a456bb7bd7a3d46e4d4ed65b19458e8c937431 node-v0.10.14-darwin-x86.tar.gz |
|||
9797f93df6085796ccad0f84a65fcdee46aaeedf node-v0.10.14-linux-x64.tar.gz |
|||
f40ade7d212be254a67994f86f598b1c1c0b7b4c node-v0.10.14-linux-x86.tar.gz |
|||
c187f1385224e8d4bc2b465d9677c060b399e268 node-v0.10.14-sunos-x64.tar.gz |
|||
bd8edd17eff8928ccd0adedbe63ddf3631324148 node-v0.10.14-sunos-x86.tar.gz |
|||
7654aacdcdc832387e479b2c3de731b3b6ca3d01 node-v0.10.14-x86.msi |
|||
90892d5672a75baa761afd2f238c06d4fa58cfef node-v0.10.14.pkg |
|||
b5d27b36d25bd7d45e1bb52ce0e0fdfb49dde370 node-v0.10.14.tar.gz |
|||
f2de9c77ed3914fd9139668581f970f8df698687 node.exe |
|||
b2a767985060c0719569d8fcfe7ad7e5548d952c node.exp |
|||
fa035fd44672547f8424df4a461f0a48c4cfdb97 node.lib |
|||
aaaf7b82f826dd2a0358223ea7f1a70ccf93bc77 node.pdb |
|||
9758a6374055ebfb5a2d788e1f95ebb267a5c20b pkgsrc/nodejs-ia32-0.10.14.tgz |
|||
d8ca87abc993a042030d63bcae08e85a30eef4b8 pkgsrc/nodejs-x64-0.10.14.tgz |
|||
b372293ff300dacae79c44603e878726e282b3a2 x64/node-v0.10.14-x64.msi |
|||
293a240db1cd280907a16956d4d6bb72ad9ef02a x64/node.exe |
|||
9d03fa6d751359e174586190e757efbf61869d50 x64/node.exp |
|||
8b4e097f17d4efe13a05bff7534bb23738821a9d x64/node.lib |
|||
0323632950aa90ed4bb083774b487f6287dae7a5 x64/node.pdb |
|||
``` |
|||
@ -1,58 +0,0 @@ |
|||
date: Thu Jul 25 16:57:47 PDT 2013 |
|||
version: 0.10.15 |
|||
category: release |
|||
title: Node v0.10.15 (Stable) |
|||
slug: node-v0-10-15-stable |
|||
|
|||
2013.07.25, Version 0.10.15 (Stable) |
|||
|
|||
* src: fix process.getuid() return value (Ben Noordhuis) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.15/node-v0.10.15.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.15/node-v0.10.15.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.15/node-v0.10.15-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.15/x64/node-v0.10.15-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.15/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.15/node-v0.10.15-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.15/node-v0.10.15-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.15/node-v0.10.15-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.15/node-v0.10.15-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.15/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.15/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.15/api/ |
|||
|
|||
Shasums: |
|||
``` |
|||
b812ba5b966b89180d1391a9de5ccd075fc84c65 node-v0.10.15-darwin-x64.tar.gz |
|||
f07bed2a59040d7adf3a647c953c3942b132da5c node-v0.10.15-darwin-x86.tar.gz |
|||
d236ed82967eefa726ec144301728b6a32ab8d8d node-v0.10.15-linux-x64.tar.gz |
|||
5629f83b10dc95d899268c3387895085270bb9e1 node-v0.10.15-linux-x86.tar.gz |
|||
408e52074146cfed792f20ea54e9eca4419164af node-v0.10.15-sunos-x64.tar.gz |
|||
01ed71a5b019c6a2b51750c2e287613be1df0d92 node-v0.10.15-sunos-x86.tar.gz |
|||
18c72b9394a943136ad5446599c732bc5fd5af9a node-v0.10.15-x86.msi |
|||
9dba40ed9c511faa215586d0b0f535d4ae55016c node-v0.10.15.pkg |
|||
14174896de074c244b0ed2251a95d7163d5a5e87 node-v0.10.15.tar.gz |
|||
fad9611a7f656b8097c97de7b2ed016f3f33c6f9 node.exe |
|||
ee48f297215ce12ba87998ccc06760ab3e667573 node.exp |
|||
11f354ebcccfb88133a529e6e1337185a3b60550 node.lib |
|||
230fc683b097afd33583ede1ec1f41fe4dae414b node.pdb |
|||
9d349103a53f444d1f9835989e22ebf2c906e3c0 pkgsrc/nodejs-ia32-0.10.15.tgz |
|||
bb1397b448bf2a58ce62fc3c51fb14633e840bbd pkgsrc/nodejs-x64-0.10.15.tgz |
|||
7c6fbdfe5c0154477f1dd8acd915c8c13766b9ae x64/node-v0.10.15-x64.msi |
|||
f273ef837b2bc3b8cf5b1b7a363b510cb230a9be x64/node.exe |
|||
57fcec104d9fd3af53286f15353c7cd75e961382 x64/node.exp |
|||
86afa3785280a25d183ff46bfea3a845b6b506c0 x64/node.lib |
|||
f6bc69a9c20c3965fd4969040cde9b43c7de50ff x64/node.pdb |
|||
``` |
|||
@ -1,74 +0,0 @@ |
|||
date: Fri Aug 16 12:45:21 PDT 2013 |
|||
version: 0.10.16 |
|||
category: release |
|||
title: Node v0.10.16 (Stable) |
|||
slug: node-v0-10-16-stable |
|||
|
|||
2013.08.16, Version 0.10.16 (Stable) |
|||
|
|||
* v8: back-port fix for CVE-2013-2882 |
|||
|
|||
* npm: Upgrade to 1.3.8 |
|||
|
|||
* crypto: fix assert() on malformed hex input (Ben Noordhuis) |
|||
|
|||
* crypto: fix memory leak in randomBytes() error path (Ben Noordhuis) |
|||
|
|||
* events: fix memory leak, don't leak event names (Ben Noordhuis) |
|||
|
|||
* http: Handle hex/base64 encodings properly (isaacs) |
|||
|
|||
* http: improve chunked res.write(buf) performance (Ben Noordhuis) |
|||
|
|||
* stream: Fix double pipe error emit (Eran Hammer) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.16/node-v0.10.16.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.16/node-v0.10.16.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.16/node-v0.10.16-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.16/x64/node-v0.10.16-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.16/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.16/node-v0.10.16-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.16/node-v0.10.16-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.16/node-v0.10.16-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.16/node-v0.10.16-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.16/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.16/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.16/api/ |
|||
|
|||
Shasums: |
|||
|
|||
``` |
|||
c76d0cac292784dcff16642e5b8e9b6e50bd2d1f node-v0.10.16-darwin-x64.tar.gz |
|||
0405727606cc0bfd86fe16226235d6a17cf03524 node-v0.10.16-darwin-x86.tar.gz |
|||
f651398c19cc56915c996660c8977a1da3c5cfaa node-v0.10.16-linux-arm-pi.tar.gz |
|||
784ac3b09eedc9ea2eda6d9bc8f7dd9760f40002 node-v0.10.16-linux-x64.tar.gz |
|||
8628a9679b0dd8b5521eb7009751f501b10db924 node-v0.10.16-linux-x86.tar.gz |
|||
49ebccdd4cf1b2433f64caf6430c0be050bf843c node-v0.10.16-sunos-x64.tar.gz |
|||
caf9d90e133e02f041f50056fa2be6575c606923 node-v0.10.16-sunos-x86.tar.gz |
|||
85ed82a3f0ce7fbdc6875b7d7b35474ff52ae76a node-v0.10.16-x86.msi |
|||
9e993cf61047dd5c1c1736ce372c90d184b55616 node-v0.10.16.pkg |
|||
646fd7ce38091ec9bd0c5d080a9da522edaabff7 node-v0.10.16.tar.gz |
|||
2eab45f17ad076d73c699e0b7029ef2ccb902cd6 node.exe |
|||
7f9b2b152aeb31d99f9cb728475852dcf08e4e42 node.exp |
|||
17dabe6f59c2216170c37192ce709636d9458ce8 node.lib |
|||
1b0488a644f3c45010f1da2f0fbd6915f55c646e node.pdb |
|||
c1535895c7f1b12e08432d9e7d760fa45d185013 pkgsrc/nodejs-ia32-0.10.16.tgz |
|||
68d9af8ea312603a483a15c057ccdffd39fe5ea4 pkgsrc/nodejs-x64-0.10.16.tgz |
|||
de4511ff2319f2b2e72664f0fa5cdbb97a79ca51 x64/node-v0.10.16-x64.msi |
|||
fd35dfd384a111dc52c8563125cdbe69577276b0 x64/node.exe |
|||
69b9866f0059fb7c6319d1f9bbea3886a27f29f5 x64/node.exp |
|||
6e19ddfb75eaeb41b4c18769b20ca6de997b5cd6 x64/node.lib |
|||
9e6b02883df774732ed1131c19e762cb309db917 x64/node.pdb |
|||
``` |
|||
@ -1,92 +0,0 @@ |
|||
date: Wed Aug 21 16:37:31 PDT 2013 |
|||
version: 0.10.17 |
|||
category: release |
|||
title: Node v0.10.17 (Stable) |
|||
slug: node-v0-10-17-stable |
|||
|
|||
2013.08.21, Version 0.10.17 (Stable) |
|||
|
|||
* uv: Upgrade v0.10.14 |
|||
|
|||
* http_parser: Do not accept PUN/GEM methods as PUT/GET (Chris Dickinson) |
|||
|
|||
* tls: fix assertion when ssl is destroyed at read (Fedor Indutny) |
|||
|
|||
* stream: Throw on 'error' if listeners removed (isaacs) |
|||
|
|||
* dgram: fix assertion on bad send() arguments (Ben Noordhuis) |
|||
|
|||
* readline: pause stdin before turning off terminal raw mode (Daniel Chatfield) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.17/node-v0.10.17.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.17/node-v0.10.17.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.17/node-v0.10.17-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.17/x64/node-v0.10.17-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.17/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.17/node-v0.10.17-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.17/node-v0.10.17-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.17/node-v0.10.17-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.17/node-v0.10.17-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.17/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.17/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.17/api/ |
|||
|
|||
Shasums: |
|||
``` |
|||
8502c5ec4878154b5896fca6a14ff6c83c3774a1 node-v0.10.17-darwin-x64.tar.gz |
|||
6d785ae86ea050159dfd85841a4faac830be8a2a node-v0.10.17-darwin-x86.tar.gz |
|||
244dc1a25dcd2cc252ae9315bb2da07b41381c5c node-v0.10.17-linux-x64.tar.gz |
|||
109c32b514fab374b73972dda4f4d27a33e20d5d node-v0.10.17-linux-x86.tar.gz |
|||
2e046a6e05520c7be941365830517db90b791999 node-v0.10.17-sunos-x64.tar.gz |
|||
907d73aa0e84717c342327265f0b665d09b50154 node-v0.10.17-sunos-x86.tar.gz |
|||
ac8f653545b58d009e19522e3ead8886d151b59d node-v0.10.17-x86.msi |
|||
32f160364990489e1f79593e1cdcea9dfde28125 node-v0.10.17.pkg |
|||
c9d31d5415d2cf7a09fd7abebf9f01259e9dd93b node-v0.10.17.tar.gz |
|||
33a5e3a86c391fc30080e796c46a74cefbd9104c node.exe |
|||
004ebfa938b3f14984b964dcaba061d10c32f12c node.exp |
|||
3dd092b26c742f20006fc2085b329a3e32d8e3d9 node.lib |
|||
a8d997936e240626c56df8c6c8d55b659003a644 node.pdb |
|||
165fecaab04a09a4df6b731f0e4b264bdb281644 pkgsrc/nodejs-ia32-0.10.17.tgz |
|||
0c813098a93090823b513147de7f41f920dd8569 pkgsrc/nodejs-x64-0.10.17.tgz |
|||
3cf665ad6c8f7d3040c2bfea8791f77c40c8f2a0 x64/node-v0.10.17-x64.msi |
|||
95baf773a34f85014eb67d026b7b9cd0396f96f5 x64/node.exe |
|||
ebdbcea161d44368c224fce448bf3d85e5a54f21 x64/node.exp |
|||
49d12cb3d5be6f6707b7f5c89952f81bddb69a68 x64/node.lib |
|||
0c0ef15eb6705c81137187c597cb0105bd2bc352 x64/node.pdb |
|||
``` |
|||
|
|||
Shasums: |
|||
``` |
|||
8502c5ec4878154b5896fca6a14ff6c83c3774a1 node-v0.10.17-darwin-x64.tar.gz |
|||
6d785ae86ea050159dfd85841a4faac830be8a2a node-v0.10.17-darwin-x86.tar.gz |
|||
244dc1a25dcd2cc252ae9315bb2da07b41381c5c node-v0.10.17-linux-x64.tar.gz |
|||
109c32b514fab374b73972dda4f4d27a33e20d5d node-v0.10.17-linux-x86.tar.gz |
|||
2e046a6e05520c7be941365830517db90b791999 node-v0.10.17-sunos-x64.tar.gz |
|||
907d73aa0e84717c342327265f0b665d09b50154 node-v0.10.17-sunos-x86.tar.gz |
|||
ac8f653545b58d009e19522e3ead8886d151b59d node-v0.10.17-x86.msi |
|||
32f160364990489e1f79593e1cdcea9dfde28125 node-v0.10.17.pkg |
|||
c9d31d5415d2cf7a09fd7abebf9f01259e9dd93b node-v0.10.17.tar.gz |
|||
33a5e3a86c391fc30080e796c46a74cefbd9104c node.exe |
|||
004ebfa938b3f14984b964dcaba061d10c32f12c node.exp |
|||
3dd092b26c742f20006fc2085b329a3e32d8e3d9 node.lib |
|||
a8d997936e240626c56df8c6c8d55b659003a644 node.pdb |
|||
165fecaab04a09a4df6b731f0e4b264bdb281644 pkgsrc/nodejs-ia32-0.10.17.tgz |
|||
0c813098a93090823b513147de7f41f920dd8569 pkgsrc/nodejs-x64-0.10.17.tgz |
|||
3cf665ad6c8f7d3040c2bfea8791f77c40c8f2a0 x64/node-v0.10.17-x64.msi |
|||
95baf773a34f85014eb67d026b7b9cd0396f96f5 x64/node.exe |
|||
ebdbcea161d44368c224fce448bf3d85e5a54f21 x64/node.exp |
|||
49d12cb3d5be6f6707b7f5c89952f81bddb69a68 x64/node.lib |
|||
0c0ef15eb6705c81137187c597cb0105bd2bc352 x64/node.pdb |
|||
``` |
|||
@ -1,62 +0,0 @@ |
|||
date: Wed Sep 4 11:24:48 PDT 2013 |
|||
version: 0.10.18 |
|||
category: release |
|||
title: Node v0.10.18 (Stable) |
|||
slug: node-v0-10-18-stable |
|||
|
|||
2013.09.04, Version 0.10.18 (Stable) |
|||
|
|||
* uv: Upgrade to v0.10.15 |
|||
|
|||
* stream: Don't crash on unset _events property (isaacs) |
|||
|
|||
* stream: Pass 'buffer' encoding with decoded writable chunks (isaacs) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.18/node-v0.10.18.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.18/node-v0.10.18.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.18/node-v0.10.18-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.18/x64/node-v0.10.18-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.18/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.18/node-v0.10.18-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.18/node-v0.10.18-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.18/node-v0.10.18-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.18/node-v0.10.18-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.18/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.18/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.18/api/ |
|||
|
|||
Shasums: |
|||
``` |
|||
c0219a68aa25369f4c83c5bdbb5ccc0db2cb8230 node-v0.10.18-darwin-x64.tar.gz |
|||
32261191c3b9f0988d4f132e442969714da3281f node-v0.10.18-darwin-x86.tar.gz |
|||
07923fa9613b2976b3be3a1bbe36d21b9f69f3c9 node-v0.10.18-linux-x64.tar.gz |
|||
4d4c6f485a110bf28e273020c20987c6045d2c57 node-v0.10.18-linux-x86.tar.gz |
|||
7b61c0c12fa99f8d0ab6ed0153359ed1c914e224 node-v0.10.18-sunos-x64.tar.gz |
|||
9f57be4b041058ea941b7f4c6f0a2ad9f431d46f node-v0.10.18-sunos-x86.tar.gz |
|||
fd50e0563e1ccf3efc903a33df40f86b6bfe2e62 node-v0.10.18-x86.msi |
|||
ff71d0e8003fc1b4674f98ceb912fba2161c8224 node-v0.10.18.pkg |
|||
0bc3c544ca1707ea4b8bd601706304e9c0609fe5 node-v0.10.18.tar.gz |
|||
ed35cc393d930fa05f4e1fbcadfa53e2837d59cb node.exe |
|||
5bb6f7af79fefa21ce936bdd60355d8d097c6cb6 node.exp |
|||
3581c8563d475642d07657fd639f48e595d2693d node.lib |
|||
7eb7f20b9e4dfb7d866b6d84916931630159230c node.pdb |
|||
192d7996c413e72a7f525039eca75ebdf0d5bc1f pkgsrc/nodejs-ia32-0.10.18.tgz |
|||
6c508f63bd76627ece633d04957a29bce52521c7 pkgsrc/nodejs-x64-0.10.18.tgz |
|||
8b845fe8723480f740d2efbfac3da11cb712ce66 x64/node-v0.10.18-x64.msi |
|||
dab63ee4c72612392cfa26c48808d45859cf6b4a x64/node.exe |
|||
90e37b4c9c7ea0e96a7035aa6473405da245006c x64/node.exp |
|||
1c19d9d5c6e7ced70742875a43085306b91d402d x64/node.lib |
|||
4e90849c7c96c4d2caffb64f062d91d14d152261 x64/node.pdb |
|||
``` |
|||
@ -1,70 +0,0 @@ |
|||
date: Tue Sep 24 15:09:23 PDT 2013 |
|||
version: 0.10.19 |
|||
category: release |
|||
title: Node v0.10.19 (Stable) |
|||
slug: node-v0-10-19-stable |
|||
|
|||
2013.09.24, Version 0.10.19 (Stable) |
|||
|
|||
* uv: Upgrade to v0.10.17 |
|||
|
|||
* npm: upgrade to 1.3.11 |
|||
|
|||
* readline: handle input starting with control chars (Eric Schrock) |
|||
|
|||
* configure: add mips-float-abi (soft, hard) option (Andrei Sedoi) |
|||
|
|||
* stream: objectMode transforms allow falsey values (isaacs) |
|||
|
|||
* tls: prevent duplicate values returned from read (Nathan Rajlich) |
|||
|
|||
* tls: NPN protocols are now local to connections (Fedor Indutny) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.19/node-v0.10.19.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.19/node-v0.10.19.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.19/node-v0.10.19-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.19/x64/node-v0.10.19-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.19/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.19/node-v0.10.19-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.19/node-v0.10.19-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.19/node-v0.10.19-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.19/node-v0.10.19-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.19/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.19/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.19/api/ |
|||
|
|||
Shasums: |
|||
``` |
|||
74f1db96742fcc0128d1c14d3cb808ef5c847749 node-v0.10.19-darwin-x64.tar.gz |
|||
71ef9bd63d3926a2b78a43a5d077838c43e7e2ea node-v0.10.19-darwin-x86.tar.gz |
|||
ebc6dc67276f7461dbd45496924b36949c75e7e0 node-v0.10.19-linux-x64.tar.gz |
|||
226b507f554fa5cc07296c30f08db76f5eaeb157 node-v0.10.19-linux-x86.tar.gz |
|||
3b324613b79d1c4ab3b9414b0644a3a559c2aec9 node-v0.10.19-sunos-x64.tar.gz |
|||
83cb3e58e9ac925ea22c8533cabc712625faa3f7 node-v0.10.19-sunos-x86.tar.gz |
|||
dcbe7db6d0c93f83f539f38807cd3c1923969721 node-v0.10.19-x86.msi |
|||
e6397e1df4e74864e3f0e5fc7bd24178828497f4 node-v0.10.19.pkg |
|||
39478caf7024af6d992007457540f8941104c5d9 node-v0.10.19.tar.gz |
|||
0fe9364b443e76f7364f8694751da15479417bdf node.exe |
|||
63555cdb67c2fd63411726dc691b08af520b27f6 node.exp |
|||
c4d33b56cff97c47b12df3ad237977a57d4c798d node.lib |
|||
19a603db8f8c30b1736124740a6a1c856f2d21d8 node.pdb |
|||
ca32da0335ecb09ab7316b6e18f23461e298768e pkgsrc/nodejs-ia32-0.10.19.tgz |
|||
b0b05a7f74d980720677a3232e82e23df211c122 pkgsrc/nodejs-x64-0.10.19.tgz |
|||
45aed04478346035e8dc7933d120ab636d56eac4 x64/node-v0.10.19-x64.msi |
|||
b81788c17fec167b77883dcbaf8c629ad7560c4d x64/node.exe |
|||
086761bf6ff4622714d24d7979548a37aaaea57e x64/node.exp |
|||
cc554a431039952207adfcb3997a7366ad7182e8 x64/node.lib |
|||
02d18f042f3d25663ea4d979dff8120435982079 x64/node.pdb |
|||
``` |
|||
@ -1,87 +0,0 @@ |
|||
date: Thu Mar 28 13:00:39 PDT 2013 |
|||
version: 0.10.2 |
|||
category: release |
|||
title: Node v0.10.2 (Stable) |
|||
slug: node-v0-10-2-stable |
|||
|
|||
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/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.2/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.2/api/ |
|||
|
|||
Shasums: |
|||
|
|||
``` |
|||
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 |
|||
``` |
|||
@ -1,59 +0,0 @@ |
|||
date: Mon Sep 30 15:05:41 PDT 2013 |
|||
version: 0.10.20 |
|||
category: release |
|||
title: Node v0.10.20 (Stable) |
|||
slug: node-v0-10-20-stable |
|||
|
|||
2013.09.30, Version 0.10.20 (Stable) |
|||
|
|||
* tls: fix sporadic hang and partial reads (Fedor Indutny) |
|||
- fixes "npm ERR! cb() never called!" |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.20/node-v0.10.20.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.20/node-v0.10.20.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.20/node-v0.10.20-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.20/x64/node-v0.10.20-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.20/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.20/node-v0.10.20-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.20/node-v0.10.20-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.20/node-v0.10.20-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.20/node-v0.10.20-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.20/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.20/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.20/api/ |
|||
|
|||
Shasums: |
|||
``` |
|||
6f827b5bb1184160a58e0aac711791b610c30afd node-v0.10.20-darwin-x64.tar.gz |
|||
89869942f09351a5256f9ff68c3e1c363f108e7a node-v0.10.20-darwin-x86.tar.gz |
|||
b7c0a79acddfaeda8af221acdd18640ef5c62e8a node-v0.10.20-linux-x64.tar.gz |
|||
709cd1a646447036abe3f57ea6e33bb1d411c229 node-v0.10.20-linux-x86.tar.gz |
|||
dbe318556bc7a4d7ea47947600edcdb375a92d8e node-v0.10.20-sunos-x64.tar.gz |
|||
b003527f645bfc8c65d890854e20c92edc1feb86 node-v0.10.20-sunos-x86.tar.gz |
|||
34015dac5e517492fec6584cacd2d9864056107e node-v0.10.20-x86.msi |
|||
a0408be15afd0b5d34b8762edab6420339a8c4ff node-v0.10.20.pkg |
|||
d8777ac318627c1413f01358ea5c455f0f86e4b5 node-v0.10.20.tar.gz |
|||
5f61f783345dc3663b03322d6387800d96560cd5 node.exe |
|||
bb81cb60eae4c6be9238aa05b5245f29609b6f96 node.exp |
|||
e06eab29b27de1908aa2cf624d438e15ee126640 node.lib |
|||
2495f7a88f0085df5206c0d0cb44131cf9715156 node.pdb |
|||
6036d6b1f2cf34a5055ed59b6519cb09cc6f86ff pkgsrc/nodejs-ia32-0.10.20.tgz |
|||
9b743d9a5d80758e8cd9d436e165c9569fa9d0fd pkgsrc/nodejs-x64-0.10.20.tgz |
|||
1b574ef4fe2ad61ce398415599f8f376b576e65d x64/node-v0.10.20-x64.msi |
|||
7137043329a25c36ad24d11d8e4ce6e5ff8a72b2 x64/node.exe |
|||
624c5bdb06ddd726457fa7b04197069ba021016b x64/node.exp |
|||
f61da5166124895495bd72520d6b6f730acc1cbc x64/node.lib |
|||
efa36de57eda469254fab252f24ef67c17f96f00 x64/node.pdb |
|||
``` |
|||
@ -1,71 +0,0 @@ |
|||
date: Fri Oct 18 15:39:23 PDT 2013 |
|||
version: 0.10.21 |
|||
category: release |
|||
title: Node v0.10.21 (Stable) |
|||
slug: node-v0-10-21-stable |
|||
|
|||
This release contains a security fix for the http server implementation, please |
|||
upgrade as soon as possible. Details will be released soon. |
|||
|
|||
2013.10.18, Version 0.10.21 (Stable) |
|||
|
|||
* uv: Upgrade to v0.10.18 |
|||
|
|||
* crypto: clear errors from verify failure (Timothy J Fontaine) |
|||
|
|||
* dtrace: interpret two byte strings (Dave Pacheco) |
|||
|
|||
* fs: fix fs.truncate() file content zeroing bug (Ben Noordhuis) |
|||
|
|||
* http: provide backpressure for pipeline flood (isaacs) |
|||
|
|||
* tls: fix premature connection termination (Ben Noordhuis) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.21/node-v0.10.21.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.21/node-v0.10.21.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.21/node-v0.10.21-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.21/x64/node-v0.10.21-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.21/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.21/node-v0.10.21-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.21/node-v0.10.21-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.21/node-v0.10.21-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.21/node-v0.10.21-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.21/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.21/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.21/api/ |
|||
|
|||
Shasums: |
|||
``` |
|||
fb1318fb7721aa292310599e7c6696edebcfd70d node-v0.10.21-darwin-x64.tar.gz |
|||
486235cc54d269d1961dfb150b1479ec14e83541 node-v0.10.21-darwin-x86.tar.gz |
|||
7528d2fa240a5dd88d37e4847cebec50ef40c8eb node-v0.10.21-linux-x64.tar.gz |
|||
b372abf9d9c53bfe675e2c3f71dcfdece44edddd node-v0.10.21-linux-x86.tar.gz |
|||
cb873cdff3f30aa198b52c8be3588745d2ee3933 node-v0.10.21-sunos-x64.tar.gz |
|||
020d202d7066b68f160d0ceebe8cc8306de25956 node-v0.10.21-sunos-x86.tar.gz |
|||
037ea0e3be3512da2bc94aa765fa89d61da3e275 node-v0.10.21-x86.msi |
|||
de2bd0e858f99098ef24f99f972b8088c1f0405c node-v0.10.21.pkg |
|||
b7fd2a3660635af40e3719ca0db49280d10359b2 node-v0.10.21.tar.gz |
|||
a0e3988170beee1273a2fb6d650bf17db8495c67 node.exe |
|||
99332a03aeba8a22254d671665b9b2161a64bd84 node.exp |
|||
263dafeec907bd1f28ceb8272b9caaadceacb4d6 node.lib |
|||
76d578bf352772dc4db9ebb95fb61cf18e34c80d node.pdb |
|||
b6d11b67ce7aaff5c7a456a4c85c80849a3d576e pkgsrc/nodejs-ia32-0.10.21.tgz |
|||
b116825d1d2cbcfd567f730b1c2452424508b062 pkgsrc/nodejs-x64-0.10.21.tgz |
|||
29632c5a21a4ebf89703e417852306a676f6ede8 x64/node-v0.10.21-x64.msi |
|||
033b0a2b57e031a9e47f0b28eb4dc50a5389b592 x64/node.exe |
|||
f62b53229d77eaddf1f3a7909ef6533eea0e2295 x64/node.exp |
|||
8d5cfe83c3bc78ddcf79de9d065d1b4f2af9347e x64/node.lib |
|||
6844e78e9ba80bfa48f6c150544e3e73d83dd316 x64/node.pdb |
|||
``` |
|||
@ -1,74 +0,0 @@ |
|||
date: Tue Nov 12 12:52:56 PST 2013 |
|||
version: 0.10.22 |
|||
category: release |
|||
title: Node v0.10.22 (Stable) |
|||
slug: node-v0-10-22-stable |
|||
|
|||
2013.11.12, Version 0.10.22 (Stable) |
|||
|
|||
* npm: Upgrade to 1.3.14 |
|||
|
|||
* uv: Upgrade to v0.10.19 |
|||
|
|||
* child_process: don't assert on stale file descriptor events (Fedor Indutny) |
|||
|
|||
* darwin: Fix "Not Responding" in Mavericks activity monitor (Fedor Indutny) |
|||
|
|||
* debugger: Fix bug in sb() with unnamed script (Maxim Bogushevich) |
|||
|
|||
* repl: do not insert duplicates into completions (Maciej Małecki) |
|||
|
|||
* src: Fix memory leak on closed handles (Timothy J Fontaine) |
|||
|
|||
* tls: prevent stalls by using read(0) (Fedor Indutny) |
|||
|
|||
* v8: use correct timezone information on Solaris (Maciej Małecki) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.22/node-v0.10.22.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.22/node-v0.10.22.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.22/node-v0.10.22-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.22/x64/node-v0.10.22-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.22/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.22/node-v0.10.22-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.22/node-v0.10.22-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.22/node-v0.10.22-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.22/node-v0.10.22-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.22/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.22/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.22/api/ |
|||
|
|||
Shasums: |
|||
``` |
|||
3082a8d13dfafa7212a7f75bd0a83447fb4d7b99 node-v0.10.22-darwin-x64.tar.gz |
|||
dca37fa37c8ce3c0df68e74643ed822bec7a12b3 node-v0.10.22-darwin-x86.tar.gz |
|||
3739f75bbb85c920a237ceb1c34cb872409d61f7 node-v0.10.22-linux-x64.tar.gz |
|||
7e99b654c21bc2a5cbccc33f1bae3ce6e26b3d12 node-v0.10.22-linux-x86.tar.gz |
|||
3dfb3585386ca0645ba02b5ad06014ddccda8cbe node-v0.10.22-sunos-x64.tar.gz |
|||
e6004f073fc81826335dc0c8fba04a82beada0bc node-v0.10.22-sunos-x86.tar.gz |
|||
3beff0c7893e39df54e416307b624eb642bffa62 node-v0.10.22-x86.msi |
|||
b4433b98f87f3f06130adad410e2fb5f959bbf37 node-v0.10.22.pkg |
|||
d7c6a39dfa714eae1f8da7a00c9a07efd74a03b3 node-v0.10.22.tar.gz |
|||
0ff278f5d6225d2be2a51bd4c7ba8fa0d15e98a4 node.exe |
|||
6cded62495794c53f6642745d34cbeb7a28266b1 node.exp |
|||
caaa11790ac8ec40d074e141afa7ffa611f216b4 node.lib |
|||
3c7592832d403c93a17b29852f2c828760a45128 node.pdb |
|||
f335aef2844a6bf9d8d5a9782e7c631d730acc2e pkgsrc/nodejs-ia32-0.10.22.tgz |
|||
6d47f98efd86faa71e1e9887aa63916e884bb2a8 pkgsrc/nodejs-x64-0.10.22.tgz |
|||
c3c169304c6371ee7bd119151bcbced61a322394 x64/node-v0.10.22-x64.msi |
|||
307de602a091fa2af3adaa64812200e32ee00fdc x64/node.exe |
|||
67440fca57eb4be5800434245ef1a5d16f5aea01 x64/node.exp |
|||
e6ee29859cd069ff5b8bf749a598112d9f09ed3c x64/node.lib |
|||
fee98420155b88c0c4b11616aa416d2328cec97d x64/node.pdb |
|||
``` |
|||
@ -1,86 +0,0 @@ |
|||
date: Wed Dec 11 22:10:46 PST 2013 |
|||
version: 0.10.23 |
|||
category: release |
|||
title: Node v0.10.23 (Stable) |
|||
slug: node-v0-10-23-stable |
|||
|
|||
2013.12.12, Version 0.10.23 (Stable) |
|||
|
|||
* uv: Upgrade to v0.10.20 (Timothy J Fontaine) |
|||
|
|||
* npm: Upgrade to 1.3.17 (isaacs) |
|||
|
|||
* gyp: update to 78b26f7 (Timothy J Fontaine) |
|||
|
|||
* build: include postmortem symbols on linux (Timothy J Fontaine) |
|||
|
|||
* crypto: Make Decipher._flush() emit errors. (Kai Groner) |
|||
|
|||
* dgram: fix abort when getting `fd` of closed dgram (Fedor Indutny) |
|||
|
|||
* events: do not accept NaN in setMaxListeners (Fedor Indutny) |
|||
|
|||
* events: avoid calling `once` functions twice (Tim Wood) |
|||
|
|||
* events: fix TypeError in removeAllListeners (Jeremy Martin) |
|||
|
|||
* fs: report correct path when EEXIST (Fedor Indutny) |
|||
|
|||
* process: enforce allowed signals for kill (Sam Roberts) |
|||
|
|||
* tls: emit 'end' on .receivedShutdown (Fedor Indutny) |
|||
|
|||
* tls: fix potential data corruption (Fedor Indutny) |
|||
|
|||
* tls: handle `ssl.start()` errors appropriately (Fedor Indutny) |
|||
|
|||
* tls: reset NPN callbacks after SNI (Fedor Indutny) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.23/node-v0.10.23.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.23/node-v0.10.23.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.23/node-v0.10.23-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.23/x64/node-v0.10.23-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.23/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.23/node-v0.10.23-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.23/node-v0.10.23-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.23/node-v0.10.23-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.23/node-v0.10.23-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.23/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.23/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.23/api/ |
|||
|
|||
Shasums: |
|||
``` |
|||
80980a23ec1915a0d4522fd4423a2eee25bf9ba5 node-v0.10.23-darwin-x64.tar.gz |
|||
c9c0f6772f2bda746d3997f4d821da9090dcd2a3 node-v0.10.23-darwin-x86.tar.gz |
|||
4c7d17ae61c753750e8f5ae989e3d80f7c8f89ea node-v0.10.23-linux-x64.tar.gz |
|||
afa901a312350ec8b271d402261a7882e1d3640b node-v0.10.23-linux-x86.tar.gz |
|||
30d5e06cfed35eea80d5ee4643858c157d104a85 node-v0.10.23-sunos-x64.tar.gz |
|||
2c4ce154b8595848119bb63164ca021f4fe8457e node-v0.10.23-sunos-x86.tar.gz |
|||
d51b641354a41243830ff6e3bdd1e03a7758fc38 node-v0.10.23-x86.msi |
|||
a7711fbb958350011641c218dae64c0c6f1f80a8 node-v0.10.23.pkg |
|||
8717942d1bdfa8902ce65cd33b4293d16b486c64 node-v0.10.23.tar.gz |
|||
12d1e0a6373bb2b67129c7f0ebc514b793b106af node.exe |
|||
9f107c4dba21fee76bbb5ac2fe552d40e6ae5e70 node.exp |
|||
52b4c463f8b667c24a54a0d8cd583b677706ae3c node.lib |
|||
ec619173e2e867b929d4178ecbe561639aed4cb2 node.pdb |
|||
837ff717c2842c32e0804ce6c131404fc8599d8d pkgsrc/nodejs-ia32-0.10.23.tgz |
|||
395e9fe9e32874a24febffa17adacd7e1e387e63 pkgsrc/nodejs-x64-0.10.23.tgz |
|||
56892aadf1c9d2d2bc637ee87bd08775a139b252 x64/node-v0.10.23-x64.msi |
|||
663d9dd7face6399f5c0b7d6082ec2d5b4acc2c3 x64/node.exe |
|||
601b564b73df1f4a871ed55e2e2c9aee5b28f04d x64/node.exp |
|||
523e3f96f45132d2e5e2eb39a1dbd0c5bf6b8822 x64/node.lib |
|||
2624cddcbd23c84d947af2bf2b91b1e0b64e3602 x64/node.pdb |
|||
``` |
|||
@ -1,68 +0,0 @@ |
|||
date: Thu Dec 19 09:02:48 PST 2013 |
|||
version: 0.10.24 |
|||
category: release |
|||
title: Node v0.10.24 (Stable) |
|||
slug: node-v0-10-24-stable |
|||
|
|||
2013.12.18, Version 0.10.24 (Stable) |
|||
|
|||
* uv: Upgrade to v0.10.21 |
|||
|
|||
* npm: upgrade to 1.3.21 |
|||
|
|||
* v8: backport fix for CVE-2013-{6639|6640} |
|||
|
|||
* build: unix install node and dep library headers (Timothy J Fontaine) |
|||
|
|||
* cluster, v8: fix --logfile=%p.log (Ben Noordhuis) |
|||
|
|||
* module: only cache package main (Wyatt Preul) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.24/node-v0.10.24.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.24/node-v0.10.24.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.24/node-v0.10.24-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.24/x64/node-v0.10.24-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.24/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.24/node-v0.10.24-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.24/node-v0.10.24-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.24/node-v0.10.24-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.24/node-v0.10.24-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.24/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.24/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.24/api/ |
|||
|
|||
Shasums: |
|||
``` |
|||
4a233e4e51ec24de3b2c3196b9128781665b4edc node-v0.10.24-darwin-x64.tar.gz |
|||
1b018a372d919462e8ebef29a0de4816a83e38ff node-v0.10.24-darwin-x86.tar.gz |
|||
423018f6a60b18d0dddf3007c325e0cc8cf55099 node-v0.10.24-linux-x64.tar.gz |
|||
fb99761ce4cef4a43743c1ed630b185545152264 node-v0.10.24-linux-x86.tar.gz |
|||
9719b2b636d8f5caf5495e967cbe167fd16eb160 node-v0.10.24-sunos-x64.tar.gz |
|||
84d7645d88dad9050f72c01d5f783cc018a8dc2b node-v0.10.24-sunos-x86.tar.gz |
|||
4b3cd142e691033308bfab237b6bf79a1a7f5c10 node-v0.10.24-x86.msi |
|||
74aba302d8b34e1fc93b3e0babc3f5d9bd8c09f3 node-v0.10.24.pkg |
|||
d162d01eb173cb5a0e7e46c9d706421c4c771039 node-v0.10.24.tar.gz |
|||
782c0b437f1d4205d7ba012e02157fb984d656b0 node.exe |
|||
c3bf16e3e2e268340a96fca869a1e3ce3ead46b5 node.exp |
|||
b81ceddb831981b200f04403718b2adcd24fd5ed node.lib |
|||
1c009c51c273512eb76ef3a1e36d5d1ccf1e4094 node.pdb |
|||
8c90873802c40ecadb304002401ba857ad728f9c pkgsrc/nodejs-ia32-0.10.24.tgz |
|||
94eda460e90dd59886ee2543bb55c8baea6daf1c pkgsrc/nodejs-x64-0.10.24.tgz |
|||
9b36fd16d8a6eb95c375ced0e1929b88b3dbb3e6 x64/node-v0.10.24-x64.msi |
|||
43c51bf9ff7c6aa421c4c89a4b14e0ab1cb0527a x64/node.exe |
|||
74d67c1cad72c0231fdc3498a0ca90c09e49abfb x64/node.exp |
|||
724463c1a1bd3ad386e1089f53c7fa0ca16c38b6 x64/node.lib |
|||
58a6bcec861c0a8d20e90db348d3a4fbd49e88cc x64/node.pdb |
|||
``` |
|||
@ -1,72 +0,0 @@ |
|||
date: Thu Jan 23 11:43:30 PST 2014 |
|||
version: 0.10.25 |
|||
category: release |
|||
title: Node v0.10.25 (Stable) |
|||
slug: node-v0-10-25-stable |
|||
|
|||
2014.01.23, Version 0.10.25 (Stable) |
|||
|
|||
* uv: Upgrade to v0.10.23 |
|||
|
|||
* npm: Upgrade to v1.3.24 |
|||
|
|||
* v8: Fix enumeration for objects with lots of properties |
|||
|
|||
* child_process: fix spawn() optional arguments (Sam Roberts) |
|||
|
|||
* cluster: report more errors to workers (Fedor Indutny) |
|||
|
|||
* domains: exit() only affects active domains (Ryan Graham) |
|||
|
|||
* src: OnFatalError handler must abort() (Timothy J Fontaine) |
|||
|
|||
* stream: writes may return false but forget to emit drain (Yang Tianyang) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.25/node-v0.10.25.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.25/node-v0.10.25.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.25/node-v0.10.25-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.25/x64/node-v0.10.25-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.25/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.25/node-v0.10.25-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.25/node-v0.10.25-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.25/node-v0.10.25-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.25/node-v0.10.25-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.25/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.25/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.25/api/ |
|||
|
|||
Shasums: |
|||
``` |
|||
b347508376ceef724b464e6009ec2daead7ea572 node-v0.10.25-darwin-x64.tar.gz |
|||
f7b3c7a36b45a83360bcd9e541e64bf18ef29272 node-v0.10.25-darwin-x86.tar.gz |
|||
7c75e7e13561be1222bddd438a84a8f228fe1bc3 node-v0.10.25-linux-x64.tar.gz |
|||
16a2c861de5b27ef907dc18253fcd4f33d506662 node-v0.10.25-linux-x86.tar.gz |
|||
05bdc1cd7933ccfa95c2f1f058ff0125eacbdc2d node-v0.10.25-sunos-x64.tar.gz |
|||
250a48c9a2b6c6a8a6feebb0d7d33f96bf8d82f4 node-v0.10.25-sunos-x86.tar.gz |
|||
ce78cc8b49e339f71888f627c4e985dda0a83e27 node-v0.10.25-x86.msi |
|||
abab975e86250b51a7434d229d13b30acdf4e82e node-v0.10.25.pkg |
|||
1e330b4fbb6f7bb858a0b37d8573dd4956f40885 node-v0.10.25.tar.gz |
|||
e3779ed14a68dc6f711ead628fe11a127d09547c node.exe |
|||
35521b6142d39fa371aba7d1fda87a1836db78e4 node.exp |
|||
35eb46e5d04fdb1c1417876d1712b85eea6be03c node.lib |
|||
cc749498572b4cf4b277225404beefdd75a4e903 node.pdb |
|||
9bf1bf3a59a3f0dc0fd32f9504e8011e5b4ebc42 pkgsrc/nodejs-ia32-0.10.25.tgz |
|||
f4a6e7d561c321b917c1b6a021fe38cd330a374e pkgsrc/nodejs-x64-0.10.25.tgz |
|||
aab984860cc02e1d27a0932c4c8d34e5e3551ebf x64/node-v0.10.25-x64.msi |
|||
d2f884d75d5f30693f62625787f27fb2a8824178 x64/node.exe |
|||
75cdbe43984c9a9f6c5f1e5875fa7422c97b2d62 x64/node.exp |
|||
108c2d9dd6ecf7cad83c4cb5cd62303f51c5570a x64/node.lib |
|||
a7c37dadc994c281d08f6a55bfbd01ecf738fe66 x64/node.pdb |
|||
``` |
|||
@ -1,77 +0,0 @@ |
|||
date: Wed Apr 3 11:24:08 PDT 2013 |
|||
version: 0.10.3 |
|||
category: release |
|||
title: Node v0.10.3 (Stable) |
|||
slug: node-v0-10-3-stable |
|||
|
|||
2013.04.03, Version 0.10.3 (Stable) |
|||
|
|||
* npm: Upgrade to 1.2.17 |
|||
|
|||
* child_process: acknowledge sent handles (Fedor Indutny) |
|||
|
|||
* etw: update prototypes to match dtrace provider (Timothy J Fontaine) |
|||
|
|||
* dtrace: pass more arguments to probes (Dave Pacheco) |
|||
|
|||
* build: allow building with dtrace on osx (Dave Pacheco) |
|||
|
|||
* http: Remove legacy ECONNRESET workaround code (isaacs) |
|||
|
|||
* http: Ensure socket cleanup on client response end (isaacs) |
|||
|
|||
* tls: Destroy socket when encrypted side closes (isaacs) |
|||
|
|||
* repl: isSyntaxError() catches "strict mode" errors (Nathan Rajlich) |
|||
|
|||
* crypto: Pass options to ctor calls (isaacs) |
|||
|
|||
* src: tie process.versions.uv to uv_version_string() (Ben Noordhuis) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.3/node-v0.10.3.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.3/node-v0.10.3.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.3/node-v0.10.3-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.3/x64/node-v0.10.3-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.3/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.3/node-v0.10.3-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.3/node-v0.10.3-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.3/node-v0.10.3-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.3/node-v0.10.3-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.3/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.3/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.3/api/ |
|||
|
|||
Shasums: |
|||
|
|||
``` |
|||
9b2f0936ee60aa65f6a5053e82440508aa9be0a7 node-v0.10.3-darwin-x64.tar.gz |
|||
f0392db831ca58c1f7b2d857d7e8cc601ea8b022 node-v0.10.3-darwin-x86.tar.gz |
|||
9a375e77f9994fbd4afd741bae64c548f2a43a64 node-v0.10.3-linux-x64.tar.gz |
|||
3323da517271e45a3850b169b10ef3d254a263a9 node-v0.10.3-linux-x86.tar.gz |
|||
0026e2453a3940ed16b9569b8187943ccf0aeb45 node-v0.10.3-sunos-x64.tar.gz |
|||
af88ad2dc98368b36f1aafc7b79f8378169fc56e node-v0.10.3-sunos-x86.tar.gz |
|||
e057c8841ddbe4dc8bc155a28b7e07dbe3d108d1 node-v0.10.3-x86.msi |
|||
a37575d47de5696b8abb2e12dc3e9d0cdb5d17f6 node-v0.10.3.pkg |
|||
4a1feb4ac18ede9e7193921f59fc181c88b1c7ba node-v0.10.3.tar.gz |
|||
9d9266d1e69bfe24837c67ff755f055fd049cd48 node.exe |
|||
8762416a5e0d71e285215efde181c7242f3f2c6f node.exp |
|||
5c05f332070a77900010f15c1074c4e86e20fa0d node.lib |
|||
a8dc61535f6ae5fd13bce9cdca989ffc113a4080 node.pdb |
|||
b834751b2e9f18e6ef38cf9fe5331e6073e3cab2 x64/node-v0.10.3-x64.msi |
|||
932c30a53f546717f00de063ee09fc8ce603dd2a x64/node.exe |
|||
a3e91038e027c91a555116d2c20742eea2e9378f x64/node.exp |
|||
d60bb0f9026df9dcc17cff0267964032aaf46712 x64/node.lib |
|||
f645a2d63179ae749defe13c653cf1777dd9021a x64/node.pdb |
|||
``` |
|||
@ -1,85 +0,0 @@ |
|||
date: Thu Apr 11 10:52:56 PDT 2013 |
|||
version: 0.10.4 |
|||
category: release |
|||
title: Node v0.10.4 (Stable) |
|||
slug: node-v0-10-4-stable |
|||
|
|||
2013.04.11, Version 0.10.4 (Stable) |
|||
|
|||
* uv: Upgrade to 0.10.4 |
|||
|
|||
* npm: Upgrade to 1.2.18 |
|||
|
|||
* v8: Avoid excessive memory growth in JSON.parse (Fedor Indutny) |
|||
|
|||
* child_process, cluster: fix O(n*m) scan of cmd string (Ben Noordhuis) |
|||
|
|||
* net: fix socket.bytesWritten Buffers support (Fedor Indutny) |
|||
|
|||
* buffer: fix offset checks (Łukasz Walukiewicz) |
|||
|
|||
* stream: call write cb before finish event (isaacs) |
|||
|
|||
* http: Support write(data, 'hex') (isaacs) |
|||
|
|||
* crypto: dh secret should be left-padded (Fedor Indutny) |
|||
|
|||
* process: expose NODE_MODULE_VERSION in process.versions (Rod Vagg) |
|||
|
|||
* crypto: fix constructor call in crypto streams (Andreas Madsen) |
|||
|
|||
* net: account for encoding in .byteLength (Fedor Indutny) |
|||
|
|||
* net: fix buffer iteration in bytesWritten (Fedor Indutny) |
|||
|
|||
* crypto: zero is not an error if writing 0 bytes (Fedor Indutny) |
|||
|
|||
* tls: Re-enable check of CN-ID in cert verification (Tobias Müllerleile) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.4/node-v0.10.4.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.4/node-v0.10.4.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.4/node-v0.10.4-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.4/x64/node-v0.10.4-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.4/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.4/node-v0.10.4-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.4/node-v0.10.4-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.4/node-v0.10.4-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.4/node-v0.10.4-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.4/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.4/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.4/api/ |
|||
|
|||
Shasums: |
|||
|
|||
``` |
|||
0bebde7d5d698e93fd96ad1b5d223166cd0c5892 node-v0.10.4-darwin-x64.tar.gz |
|||
8d847a68f8178b102c72c3f35861f496e12fe455 node-v0.10.4-darwin-x86.tar.gz |
|||
28e3a4d2702a13454a3c1d9e1035ee07ef8764bc node-v0.10.4-linux-x64.tar.gz |
|||
839be3dfe4504072e372b2a3f597e0b0f4e26331 node-v0.10.4-linux-x86.tar.gz |
|||
94d68094afacb70b71a3393f07f81eff6e8a14f1 node-v0.10.4-sunos-x64.tar.gz |
|||
6b287dcdb9498cb7d59acbab8faaea4455ffe2c4 node-v0.10.4-sunos-x86.tar.gz |
|||
1863868f40d4e3af876d21976d9b06a9e99d1dcf node-v0.10.4-x86.msi |
|||
bafb80cff0ada4cdfd98c917459d627d7df408d5 node-v0.10.4.pkg |
|||
901c1410b7c28a79644292567d3384255f3a6274 node-v0.10.4.tar.gz |
|||
73b5f6eaea8417f4b937bf99812263dc170696e0 node.exe |
|||
85064a019b8e6416152ae609ace81469331f773c node.exp |
|||
e5b26b8480c3979ddab5ea3bf6bfb0fbef9ecb54 node.lib |
|||
0098965a1a2206a1fc148ab776d182018b80d0ba node.pdb |
|||
31bd64f33436fa543f0599f80c5df97c14b10224 x64/node-v0.10.4-x64.msi |
|||
8280dbeb5a1296fe3496f57376a619467c4c6263 x64/node.exe |
|||
e317e0db2693e42851f3774a20dc98e02a9a90fe x64/node.exp |
|||
7f0aa389465ac7983a4c099671bb52c7a6988676 x64/node.lib |
|||
a7fb9a08d6337225dd8c5b1db5fb95a2f39fd773 x64/node.pdb |
|||
``` |
|||
@ -1,73 +0,0 @@ |
|||
date: Tue Apr 23 14:05:49 PDT 2013 |
|||
version: 0.10.5 |
|||
category: release |
|||
title: Node v0.10.5 (Stable) |
|||
slug: node-v0-10-5-stable |
|||
|
|||
2013.04.23, Version 0.10.5 (Stable) |
|||
|
|||
* uv: Upgrade to 0.10.5 (isaacs) |
|||
|
|||
* build: added support for Visual Studio 2012 (Miroslav Bajtoš) |
|||
|
|||
* http: Don't try to destroy nonexistent sockets (isaacs) |
|||
|
|||
* crypto: LazyTransform on properties, not methods (isaacs) |
|||
|
|||
* assert: put info in err.message, not err.name (Ryan Doenges) |
|||
|
|||
* dgram: fix no address bind() (Ben Noordhuis) |
|||
|
|||
* handle_wrap: fix NULL pointer dereference (Ben Noordhuis) |
|||
|
|||
* os: fix unlikely buffer overflow in os.type() (Ben Noordhuis) |
|||
|
|||
* stream: Fix unshift() race conditions (isaacs) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.5/node-v0.10.5.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.5/node-v0.10.5.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.5/node-v0.10.5-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.5/x64/node-v0.10.5-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.5/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.5/node-v0.10.5-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.5/node-v0.10.5-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.5/node-v0.10.5-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.5/node-v0.10.5-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.5/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.5/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.5/api/ |
|||
|
|||
Shasums: |
|||
|
|||
``` |
|||
b3a5122fdfa67a7b69c4c80e5cca4c8d700c9461 node-v0.10.5-darwin-x64.tar.gz |
|||
c95d027af3d774c8650be634b9fe2555c3381c88 node-v0.10.5-darwin-x86.tar.gz |
|||
6bdc5d48368a4425f289c3babe457bb427cb2476 node-v0.10.5-linux-x64.tar.gz |
|||
99643f86f6441436822a0feebd397a3c515d03f9 node-v0.10.5-linux-x86.tar.gz |
|||
72a41a467dcfd96b4244ef8089cf03cf68fa0788 node-v0.10.5-sunos-x64.tar.gz |
|||
6388c920ce5500f6523b718c864ccee2f3c4e72e node-v0.10.5-sunos-x86.tar.gz |
|||
1dc49f8689c90c84fd335d8023d7c9f01b0183ab node-v0.10.5-x86.msi |
|||
4a7c59c37afa8ac7b6f2d1d83b34de30f24642ae node-v0.10.5.pkg |
|||
99b92864f4a277debecb4c872ea7202c9aa6996f node-v0.10.5.tar.gz |
|||
6f094dd0ce62bcdbf6f36cc67413b1b194d98616 node.exe |
|||
9b1b33512631bc58f6480db5587832c79851afc5 node.exp |
|||
01788dd89217706b9ca8e7ef9f9136d06236a191 node.lib |
|||
1890ff369a65222539ddfd705a40699ca37d476a node.pdb |
|||
368e7b7b56cb2c05dc818449cf7962a36b1a9cb7 x64/node-v0.10.5-x64.msi |
|||
8624e85306a27079bf4cc3ff25c6914fd59a4e29 x64/node.exe |
|||
c9c0c0b45eebdfaf93b5e6bda38b23052308dab3 x64/node.exp |
|||
0fb687c156204c59e26dff2302f8f9fab73cc3f2 x64/node.lib |
|||
afdecf9ffdce0c28815ae5fc24d6e0defa71ed32 x64/node.pdb |
|||
``` |
|||
@ -1,65 +0,0 @@ |
|||
date: Tue May 14 14:32:31 PDT 2013 |
|||
version: 0.10.6 |
|||
category: release |
|||
title: Node v0.10.6 (Stable) |
|||
slug: node-v0-10-6-stable |
|||
|
|||
2013.05.14, Version 0.10.6 (Stable) |
|||
|
|||
* module: Deprecate require.extensions (isaacs) |
|||
|
|||
* stream: make Readable.wrap support objectMode, empty streams (Daniel Moore) |
|||
|
|||
* child_process: fix handle delivery (Ben Noordhuis) |
|||
|
|||
* crypto: Fix performance regression (isaacs) |
|||
|
|||
* src: DRY string encoding/decoding (isaacs) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.6/node-v0.10.6.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.6/node-v0.10.6.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.6/node-v0.10.6-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.6/x64/node-v0.10.6-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.6/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.6/node-v0.10.6-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.6/node-v0.10.6-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.6/node-v0.10.6-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.6/node-v0.10.6-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.6/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.6/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.6/api/ |
|||
|
|||
Shasums: |
|||
|
|||
``` |
|||
24982edc3b6aafd019273fa5e8a2031353314b56 node-v0.10.6-darwin-x64.tar.gz |
|||
e208c5dc83864a7f35f9df60ee35642bc7dd689c node-v0.10.6-darwin-x86.tar.gz |
|||
ab2ad473f5aa0f1c5adb50b9ea47fd05010bca2c node-v0.10.6-linux-x64.tar.gz |
|||
29cdac417449f088e6e6fa67d57c9205d8bff6c5 node-v0.10.6-linux-x86.tar.gz |
|||
66e3a9e53af6d8f27c690a77c329a2bd108965ac node-v0.10.6-sunos-x64.tar.gz |
|||
05bda089f4f702deddb8e593653676ede5f0e10b node-v0.10.6-sunos-x86.tar.gz |
|||
6ceb80be28c63f2c57e8479755d206400b205c46 node-v0.10.6-x86.msi |
|||
cd0acf9b332c30aba6a72979d3373e342fad6b95 node-v0.10.6.pkg |
|||
fa06101af8890eeaf997bd2620d7742b71a7223c node-v0.10.6.tar.gz |
|||
a2a2befa62b3cd2da9c2e51204df017e0f0c0cae node.exe |
|||
8401647a2f8fb3486fa08d7e603822ae12cf6dee node.exp |
|||
8ab923eb23584310874a4f63d71244cca5bfc0f8 node.lib |
|||
b9042fec324b202853f7f1d8b1d26ea49d944913 node.pdb |
|||
647a2ea899113e14d8f0894aa969ffd3a5d407c6 x64/node-v0.10.6-x64.msi |
|||
021048aa29fce5ce200b22896fd5f1b053f0d40c x64/node.exe |
|||
adbdc6112b3172c259a3fa9e07b7d456a0c65beb x64/node.exp |
|||
226af9033a41c96c68ade96cecedcf1289414424 x64/node.lib |
|||
cca201bfe38713ffde4a0cad70cb3a5325097257 x64/node.pdb |
|||
``` |
|||
@ -1,65 +0,0 @@ |
|||
date: Fri May 17 14:36:03 PDT 2013 |
|||
version: 0.10.7 |
|||
category: release |
|||
title: Node v0.10.7 (Stable) |
|||
slug: node-v0-10-7-stable |
|||
|
|||
2013.05.17, Version 0.10.7 (Stable) |
|||
|
|||
* uv: upgrade to v0.10.7 |
|||
|
|||
* npm: Upgrade to 1.2.21 |
|||
|
|||
* crypto: Don't ignore verify encoding argument (isaacs) |
|||
|
|||
* buffer, crypto: fix default encoding regression (Ben Noordhuis) |
|||
|
|||
* timers: fix setInterval() assert (Ben Noordhuis) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.7/node-v0.10.7.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.7/node-v0.10.7.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.7/node-v0.10.7-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.7/x64/node-v0.10.7-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.7/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.7/node-v0.10.7-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.7/node-v0.10.7-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.7/node-v0.10.7-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.7/node-v0.10.7-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.7/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.7/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.7/api/ |
|||
|
|||
Shasums: |
|||
|
|||
``` |
|||
95d64001ccd5a17c2c25f1ae4b0358b6131e7cb8 node-v0.10.7-darwin-x64.tar.gz |
|||
c34f991cc0752679002f763b2b3c8927babb08d8 node-v0.10.7-darwin-x86.tar.gz |
|||
673c287bcf671eced6aa94637b7c91e5149f4c56 node-v0.10.7-linux-x64.tar.gz |
|||
9f14d4f9add721148f0c15f093d3e6b1fa3820c9 node-v0.10.7-linux-x86.tar.gz |
|||
1fb7dc4195a9dd228039f5f7ca2cb9f7c35b105a node-v0.10.7-sunos-x64.tar.gz |
|||
d84cd8afb50df44483b9dab0c65d5c81f07ac4a2 node-v0.10.7-sunos-x86.tar.gz |
|||
d7794a7da103d639fdec4b9e7236a5a0a4330297 node-v0.10.7-x86.msi |
|||
0524ad9268095c9ed435708268e6aad7968309f7 node-v0.10.7.pkg |
|||
f2bde505faf6ffed3084c8e550a9e6d4311f13d5 node-v0.10.7.tar.gz |
|||
5f50384766dd5435dba4989d95032452754150bf node.exe |
|||
809f12f84c8495d101ce6ae443890e8533695ab0 node.exp |
|||
5a7355e2f75ae3f72deab75f4c9f93e4e5325584 node.lib |
|||
6e45953bd7488a4236c43fea93b05da0854158a7 node.pdb |
|||
fc5e3b2b1c74e53f1d214a9e2d5af30fe5247381 x64/node-v0.10.7-x64.msi |
|||
aa67bbd421f26b37fa09ce30d5e626106677853e x64/node.exe |
|||
b289989a156d4d7055554962e6f00ba3e380aeea x64/node.exp |
|||
0dbecc5007c9e28ad488d2058157f8360eaed958 x64/node.lib |
|||
e4b63472787a3db6a3d85237e8c7fb4d973f797b x64/node.pdb |
|||
``` |
|||
@ -1,75 +0,0 @@ |
|||
date: Fri May 24 15:43:01 PDT 2013 |
|||
version: 0.10.8 |
|||
category: release |
|||
title: Node v0.10.8 (Stable) |
|||
slug: node-v0-10-8-stable |
|||
|
|||
2013.05.24, Version 0.10.8 (Stable) |
|||
|
|||
* v8: update to 3.14.5.9 |
|||
|
|||
* uv: upgrade to 0.10.8 |
|||
|
|||
* npm: Upgrade to 1.2.23 |
|||
|
|||
* http: remove bodyHead from 'upgrade' events (Nathan Zadoks) |
|||
|
|||
* http: Return true on empty writes, not false (isaacs) |
|||
|
|||
* http: save roundtrips, convert buffers to strings (Ben Noordhuis) |
|||
|
|||
* configure: respect the --dest-os flag consistently (Nathan Rajlich) |
|||
|
|||
* buffer: throw when writing beyond buffer (Trevor Norris) |
|||
|
|||
* crypto: Clear error after DiffieHellman key errors (isaacs) |
|||
|
|||
* string_bytes: strip padding from base64 strings (Trevor Norris) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.8/node-v0.10.8.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.8/node-v0.10.8.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.8/node-v0.10.8-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.8/x64/node-v0.10.8-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.8/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.8/node-v0.10.8-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.8/node-v0.10.8-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.8/node-v0.10.8-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.8/node-v0.10.8-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.8/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.8/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.8/api/ |
|||
|
|||
Shasums: |
|||
|
|||
``` |
|||
c1b81939e55d42fd7a90ec88ab23fd7a411ed77c node-v0.10.8-darwin-x64.tar.gz |
|||
4474b8d4222efd6f6076243a4aa78e72760ee01a node-v0.10.8-darwin-x86.tar.gz |
|||
898283b1ba8a9732c98ce38a89dc15af23291702 node-v0.10.8-linux-x64.tar.gz |
|||
2e15464289f618245fc6f420191490c144d81be3 node-v0.10.8-linux-x86.tar.gz |
|||
9a36b001ce5eef52641b836a42d1fc69c516d329 node-v0.10.8-sunos-x64.tar.gz |
|||
490d9a6d2a300fd2750a4a227288aed67a767713 node-v0.10.8-sunos-x86.tar.gz |
|||
96218cb0c14fbcaa76165fbe5a3af402883f898b node-v0.10.8-x86.msi |
|||
a713f339195dd009d2614fac25b61bc88295f063 node-v0.10.8.pkg |
|||
d650a09ae868bb04f424e3560658c15b9a885b5b node-v0.10.8.tar.gz |
|||
38034b7a6bca2dbe3aaacc3cc8aa9920394baaf7 node.exe |
|||
19cd4ae9f3edeaa259e5ca84abd28dea400a91d7 node.exp |
|||
1ccffaf0ff0f4bb11e8d23a2938366fd87b3e583 node.lib |
|||
079f617ef81507a6b5fe7e8bd1f5a2f109a574ec node.pdb |
|||
985d55d1ba49f47354ba13a419d678bf73634ef9 x64/node-v0.10.8-x64.msi |
|||
25d4d74c73cd57346094979e5c51c5b16d6dcb83 x64/node.exe |
|||
19587e8301371e721695c7aed335f74c6873dfaf x64/node.exp |
|||
4a002dd8a1742431fc99a2a92580a3040a796f2c x64/node.lib |
|||
8d18200f9fe81805fe81201355d9f3509bd0c81b x64/node.pdb |
|||
``` |
|||
@ -1,67 +0,0 @@ |
|||
date: Thu May 30 11:12:12 PDT 2013 |
|||
version: 0.10.9 |
|||
category: release |
|||
title: Node v0.10.9 (Stable) |
|||
slug: node-v0-10-9-stable |
|||
|
|||
2013.05.30, Version 0.10.9 (Stable) |
|||
|
|||
* npm: Upgrade to 1.2.24 |
|||
|
|||
* uv: Upgrade to v0.10.9 |
|||
|
|||
* repl: fix JSON.parse error check (Brian White) |
|||
|
|||
* tls: proper .destroySoon (Fedor Indutny) |
|||
|
|||
* tls: invoke write cb only after opposite read end (Fedor Indutny) |
|||
|
|||
* tls: ignore .shutdown() syscall error (Fedor Indutny) |
|||
|
|||
|
|||
Source Code: http://nodejs.org/dist/v0.10.9/node-v0.10.9.tar.gz |
|||
|
|||
Macintosh Installer (Universal): http://nodejs.org/dist/v0.10.9/node-v0.10.9.pkg |
|||
|
|||
Windows Installer: http://nodejs.org/dist/v0.10.9/node-v0.10.9-x86.msi |
|||
|
|||
Windows x64 Installer: http://nodejs.org/dist/v0.10.9/x64/node-v0.10.9-x64.msi |
|||
|
|||
Windows x64 Files: http://nodejs.org/dist/v0.10.9/x64/ |
|||
|
|||
Linux 32-bit Binary: http://nodejs.org/dist/v0.10.9/node-v0.10.9-linux-x86.tar.gz |
|||
|
|||
Linux 64-bit Binary: http://nodejs.org/dist/v0.10.9/node-v0.10.9-linux-x64.tar.gz |
|||
|
|||
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.9/node-v0.10.9-sunos-x86.tar.gz |
|||
|
|||
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.9/node-v0.10.9-sunos-x64.tar.gz |
|||
|
|||
Other release files: http://nodejs.org/dist/v0.10.9/ |
|||
|
|||
Website: http://nodejs.org/docs/v0.10.9/ |
|||
|
|||
Documentation: http://nodejs.org/docs/v0.10.9/api/ |
|||
|
|||
Shasums: |
|||
|
|||
``` |
|||
b527f5cf879fd834cb70cec630fce34eb30b5a02 node-v0.10.9-darwin-x64.tar.gz |
|||
b2c9b14aa4a2aa17dd63f2ebe5a4f27171eb64f7 node-v0.10.9-darwin-x86.tar.gz |
|||
4626105fbf907c76314bf487460662e5c97e14ea node-v0.10.9-linux-x64.tar.gz |
|||
29a4aa89ca61b5a4f3c520f0f798b8b19ce2d3d3 node-v0.10.9-linux-x86.tar.gz |
|||
6d755df136dec6dc085cc6b214154245402a5372 node-v0.10.9-sunos-x64.tar.gz |
|||
2dadf9feca00bb3e681ea31ebd4086ab926a1c39 node-v0.10.9-sunos-x86.tar.gz |
|||
5ff6c7ed7174af8502f54f4476bf8de616180625 node-v0.10.9-x86.msi |
|||
7d945ed2102fcfab28e26dca5f4698b6cf0b921a node-v0.10.9.pkg |
|||
e4b2bb8c42da2ec90e6fd81da1e6b382ba499608 node-v0.10.9.tar.gz |
|||
889e9c4cb614c79fb728816790a622d13ce9ca88 node.exe |
|||
3b9b15f8ab5fc5378e05301f465114d93ade237a node.exp |
|||
3c8034b9e4eef1f46d186a266a60690edd17b1f4 node.lib |
|||
b9f1d9452f2815b43df98b40ab1b6cf2c358ad8a node.pdb |
|||
4b767d596c8a395fe22215d065f9d31b3a5b9423 x64/node-v0.10.9-x64.msi |
|||
e763bc24888254ddd992a4b7302d1ad4538ad920 x64/node.exe |
|||
eec159254e209f172bca37dc547f0bfcfa1bd87c x64/node.exp |
|||
6ae5f3a36ffba256cb8077c47a218749449f798c x64/node.lib |
|||
5c2283b50c74a8b43708fdc29cb5c314fbe2d018 x64/node.pdb |
|||
``` |
|||
Some files were not shown because too many files changed in this diff
Loading…
Reference in new issue