This commit replaces instances of io.js with Node.js, based on the
recent convergence. There are some remaining instances of io.js,
related to build and the installer.
Fixes: https://github.com/nodejs/node/issues/2361
PR-URL: https://github.com/nodejs/node/pull/2367
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: João Reis <reis@janeasystems.com>
***This is a living document, it describes the policy and priorities as they exist today but can evolve over time.***
@ -6,15 +6,15 @@
The most important consideration in every code change is the impact it will have, positive or negative, on the ecosystem (modules and applications).
io.js does not remove stdlib JS API.
Node.js does not remove stdlib JS API.
Shipping with current and well supported dependencies is the best way to ensure long term stability of the platform. When those dependencies are no longer maintained io.js will take on their continued maintenance as part of our [Long Term Support policy](#long-term-support).
Shipping with current and well supported dependencies is the best way to ensure long term stability of the platform. When those dependencies are no longer maintained Node.js will take on their continued maintenance as part of our [Long Term Support policy](#long-term-support).
io.js will continue to adopt new V8 releases.
Node.js will continue to adopt new V8 releases.
* When V8 ships a breaking change to their C++ API that can be handled by [`nan`](https://github.com/rvagg/nan)
the *minor* version of io.js will be increased.
the *minor* version of Node.js will be increased.
* When V8 ships a breaking change to their C++ API that can NOT be handled by [`nan`](https://github.com/rvagg/nan)
the *major* version of io.js will be increased.
the *major* version of Node.js will be increased.
* When new features in the JavaScript language are introduced by V8 the
*minor* version number will be increased. TC39 has stated clearly that no
backwards incompatible changes will be made to the language so it is
@ -26,23 +26,23 @@ Any API addition will cause an increase in the *minor* version.
### Long Term Support
io.js supports old versions for as long as community members are fixing bugs in them.
Node.js supports old versions for as long as community members are fixing bugs in them.
As long as there is a community back porting bug fixes we will push patch releases for those versions of io.js.
As long as there is a community back porting bug fixes we will push patch releases for those versions of Node.js.
When old versions of dependencies like V8 are no longer supported by their project io.js will take on the responsibility of maintenance to ensure continued long term support in io.js patch releases.
When old versions of dependencies like V8 are no longer supported by their project Node.js will take on the responsibility of maintenance to ensure continued long term support in Node.js patch releases.
## Channels
Channels are points of collaboration with the broader community and are not strictly scoped to a repository or branch.
* Release - Stable production ready builds. Unique version numbers following semver.
* Canary - Nightly builds w/ V8 version in Chrome Canary + changes landing to io.js. No version designation.
* Canary - Nightly builds w/ V8 version in Chrome Canary + changes landing to Node.js. No version designation.
* NG - "Next Generation." No version designation.
## NG (Next Generation)
In order for io.js to stay competitive we need to work on the next generation of the platform which will more accurately integrate and reflect the advancements in the language and the ecosystem.
In order for Node.js to stay competitive we need to work on the next generation of the platform which will more accurately integrate and reflect the advancements in the language and the ecosystem.
While this constitutes a great leap forward for the platform we will be making this leap without breaking backwards compatibility with the existing ecosystem of modules.
@ -50,9 +50,9 @@ While this constitutes a great leap forward for the platform we will be making t
## Debugging and Tracing
Debugging is one of the first things from everyone's mouth, both developer and enterprise, when describing trouble they've had with node.js/io.js.
Debugging is one of the first things from everyone's mouth, both developer and enterprise, when describing trouble they've had with Node.js.
The goal of io.js' effort is to build a healthy debugging and tracing ecosystem and not to try and build any "silver bullet" features for core (like the domains debacle).
The goal of Node.js' effort is to build a healthy debugging and tracing ecosystem and not to try and build any "silver bullet" features for core (like the domains debacle).
The [Tracing WG](https://github.com/nodejs/tracing-wg) is driving this effort:
@ -60,8 +60,8 @@ The [Tracing WG](https://github.com/nodejs/tracing-wg) is driving this effort:
* async-listener - userland module that will dogfood AsyncWrap as well as provide many often requested debugging features.
* Tracing
* Add tracing support for more platforms (LTTng, etc).
* [Unify the Tracing endpoint](https://github.com/nodejs/io.js/issues/729).
* New Chrome Debugger - Google is working on a version of Chrome's debugger that is without Chrome and can be used with io.js.
* [Unify the Tracing endpoint](https://github.com/nodejs/node/issues/729).
* New Chrome Debugger - Google is working on a version of Chrome's debugger that is without Chrome and can be used with Node.js.
Errors generated by io.js fall into two categories: JavaScript errors and system
Errors generated by Node.js fall into two categories: JavaScript errors and system
errors. All errors inherit from or are instances of JavaScript's [Error](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error)
class and are guaranteed to provide *at least* the attributes available on that
class.
@ -34,14 +34,14 @@ denote any specific circumstance of why the error occurred. Errors capture a
"stack trace" detailing the point in the program at which they were
instantiated, and may provide a description of the error.
**Note**: io.js will generate this class of error to encapsulate system
**Note**: Node.js will generate this class of error to encapsulate system
errors as well as plain JavaScript errors.
#### new Error(message)
Instantiates a new Error object and sets its `.message` property to the provided
message. Its `.stack` will represent the point in the program at which `new Error`
was called. Stack traces are subject to [V8's stack trace API](https://code.google.com/p/v8-wiki/wiki/JavaScriptStackTraceApi).
was called. Stack traces are subject to [V8's stack trace API](https://code.google.com/p/v8-wiki/wiki/JavaScriptStackTraceApi).
Stack traces only extend to the beginning of synchronous code execution, *or* a number of frames given by
`Error.stackTraceLimit`, whichever is smaller.
@ -65,15 +65,15 @@ at which this error was instantiated. An example stacktrace follows:
The first line is formatted as `<error class name>: <error message>`, and it is followed
by a series of stack frames (each line beginning with "at "). Each frame describes
a call site in the program that lead to the error being generated. V8 attempts to
display a name for each function (by variable name, function name, or object
display a name for each function (by variable name, function name, or object
method name), but occasionally it will not be able to find a suitable name. If
V8 cannot determine a name for the function, only location information will be
displayed for that frame. Otherwise, the determined function name will be displayed
with location information appended in parentheses.
with location information appended in parentheses.
Frames are **only** generated for JavaScript functions. If, for example, execution
synchronously passes through a C++ addon function called `cheetahify`, which itself
calls a JavaScript function, the frame representing the `cheetahify` call will **not**
Frames are **only** generated for JavaScript functions. If, for example, execution
synchronously passes through a C++ addon function called `cheetahify`, which itself
calls a JavaScript function, the frame representing the `cheetahify` call will **not**
be present in stacktraces:
```javascript
@ -103,14 +103,14 @@ makeFaster(); // will throw:
// at node.js:906:3
```
The location information will be one of:
The location information will be one of:
* `native`, if the frame represents a call internal to V8 (as in `[].forEach`).
* `plain-filename.js:line:column`, if the frame represents a call internal to io.js.
* `plain-filename.js:line:column`, if the frame represents a call internal to Node.js.
* `/absolute/path/to/file.js:line:column`, if the frame represents a call in a user program, or its dependencies.
It is important to note that the string representing the stacktrace is only
generated on **access**: it is lazily generated.
generated on **access**: it is lazily generated.
The number of frames captured by the stack trace is bounded by the smaller of
`Error.stackTraceLimit` or the number of available frames on the current event
@ -138,7 +138,7 @@ message`, will be the result of `targetObject.toString()`.
`constructorOpt` optionally accepts a function. If given, all frames above
`constructorOpt`, including `constructorOpt`, will be omitted from the generated
stack trace.
stack trace.
This is useful for hiding implementation details of error generation from the
end user. A common way of using this parameter is to pass the current Error
@ -177,8 +177,8 @@ range, or outside the set of options for a given function parameter. An example:
require('net').connect(-1); // throws RangeError, port should be > 0 &&<65536
```
io.js will generate and throw RangeError instances *immediately* -- they are a form
of argument validation.
Node.js will generate and throw RangeError instances *immediately* -- they are a form
of argument validation.
### Class: TypeError
@ -190,7 +190,7 @@ be considered a TypeError.
require('url').parse(function() { }); // throws TypeError, since it expected a string
```
io.js will generate and throw TypeError instances *immediately* -- they are a form
Node.js will generate and throw TypeError instances *immediately* -- they are a form
of argument validation.
### Class: ReferenceError
@ -219,7 +219,7 @@ Unless the userland program is dynamically generating and running code,
ReferenceErrors should always be considered a bug in the program, or its
dependencies.
### Class: SyntaxError
### Class: SyntaxError
A subclass of Error that indicates that a program is not valid JavaScript.
These errors may only be generated and propagated as a result of code
@ -244,9 +244,9 @@ by other contexts.
A JavaScript "exception" is a value that is thrown as a result of an invalid operation or
as the target of a `throw` statement. While it is not required that these values inherit from
`Error`, all exceptions thrown by io.js or the JavaScript runtime *will* be instances of Error.
`Error`, all exceptions thrown by Node.js or the JavaScript runtime *will* be instances of Error.
Some exceptions are *unrecoverable* at the JavaScript layer. These exceptions will always bring
Some exceptions are *unrecoverable* at the JavaScript layer. These exceptions will always bring
down the process. These are usually failed `assert()` checks or `abort()` calls in the C++ layer.
## System Errors
@ -257,7 +257,7 @@ react to. They are generated at the syscall level: an exhaustive list of error
codes and their meanings is available by running `man 2 intro` or `man 3 errno`
on most Unices; or [online](http://man7.org/linux/man-pages/man3/errno.3.html).
In io.js, system errors are represented as augmented Error objects -- not full
In Node.js, system errors are represented as augmented Error objects -- not full
subclasses, but instead an error instance with added members.
### Class: System Error
@ -275,7 +275,7 @@ letters, and may be referenced in `man 2 intro`.
### Common System Errors
This list is **not exhaustive**, but enumerates many of the common system errors when
writing a io.js program. An exhaustive list may be found [here](http://man7.org/linux/man-pages/man3/errno.3.html).
writing a Node.js program. An exhaustive list may be found [here](http://man7.org/linux/man-pages/man3/errno.3.html).
#### EPERM: Operation not permitted
@ -289,7 +289,7 @@ does not exist -- no entity (file or directory) could be found by the given path
#### EACCES: Permission denied
An attempt was made to access a file in a way forbidden by its file access
An attempt was made to access a file in a way forbidden by its file access
permissions.
#### EEXIST: File exists
@ -300,7 +300,7 @@ not exist.
#### ENOTDIR: Not a directory
A component of the given pathname existed, but was not a directory as expected.
Commonly raised by [fs.readdir](fs.html#fs_fs_readdir_path_callback).
Commonly raised by [fs.readdir](fs.html#fs_fs_readdir_path_callback).
#### EISDIR: Is a directory
@ -315,7 +315,7 @@ at least one has been closed.
Commonly encountered when opening many files at once in parallel, especially
on systems (in particular, OS X) where there is a low file descriptor limit
for processes. To remedy a low limit, run `ulimit -n 2048` in the same shell
that will run the io.js process.
that will run the Node.js process.
#### EPIPE: Broken pipe
@ -356,7 +356,7 @@ often a sign that a connected socket was not `.end()`'d appropriately.
<!--type=misc-->
All io.js APIs will treat invalid arguments as exceptional -- that is, if passed
All Node.js APIs will treat invalid arguments as exceptional -- that is, if passed
invalid arguments, they will *immediately* generate and throw the error as an
exception, even if they are an otherwise asynchronous API.
@ -364,7 +364,7 @@ Synchronous APIs (like
[fs.readFileSync](fs.html#fs_fs_readfilesync_filename_options)) will throw the
error. The act of *throwing* a value (in this case, the error) turns the value
into an **exception**. Exceptions may be caught using the `try { } catch(err)
{ }` construct.
{ }` construct.
Asynchronous APIs have **two** mechanisms for error propagation; one mechanism
for APIs that represent a single operation, and one for APIs that represent
This document describes the technical aspects of the io.js release process. The intended audience is those who have been authorized by the Node.js Foundation Technical Steering Committee (TSC) to create, promote and sign official release builds for io.js, hosted on <https://iojs.org>.
This document describes the technical aspects of the node.js release process. The intended audience is those who have been authorized by the Node.js Foundation Technical Steering Committee (TSC) to create, promote and sign official release builds for node.js, hosted on <https://nodejs.org>.
## Who can make a release?
Release authorization is given by the io.js TC. Once authorized, an individual must be have the following:
Release authorization is given by the node.js TSC. Once authorized, an individual must be have the following:
### 1. Jenkins Release Access
@ -13,21 +13,21 @@ There are three relevant Jenkins jobs that should be used for a release flow:
**a.** **Test runs:****[iojs+any-pr+multi](https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/)** is used for a final full-test run to ensure that the current *HEAD* is stable.
**b.** **Nightly builds:** (optional) **[iojs+release](https://jenkins-iojs.nodesource.com/job/iojs+release/)** can be used to create a nightly release for the current *HEAD* if public test releases are required. Builds triggered with this job are published straight to <http://iojs.org/download/nightly/> and are available for public download.
**b.** **Nightly builds:** (optional) **[iojs+release](https://jenkins-iojs.nodesource.com/job/iojs+release/)** can be used to create a nightly release for the current *HEAD* if public test releases are required. Builds triggered with this job are published straight to <http://nodejs.org/download/nightly/> and are available for public download.
**c.** **Release builds:****[iojs+release](https://jenkins-iojs.nodesource.com/job/iojs+release/)** does all of the work to build all required release assets. Promotion of the release files is a manual step once they are ready (see below).
The [io.js build team](https://github.com/nodejs/build) is able to provide this access to individuals authorized by the TC.
### 2. <iojs.org> Access
The [Node.js build team](https://github.com/nodejs/build) is able to provide this access to individuals authorized by the TC.
The _dist_ user on iojs.org controls the assets available in <http://iojs.org/download/> (note that <http://iojs.org/dist/> is an alias for <https://iojs.org/download/release/>).
### 2. <nodejs.org> Access
The _dist_ user on nodejs.org controls the assets available in <http://nodejs.org/download/> (note that <http://nodejs.org/dist/> is an alias for <https://nodejs.org/download/release/>).
The Jenkins release build slaves upload their artifacts to the web server as the _staging_ user, the _dist_ user has access to move these assets to public access (the _staging_ user does not, for security purposes).
Nightly builds are promoted automatically on the server by a cron task for the _dist_ user.
Release builds require manual promotion by an individual with SSH access to the server as the _dist_ user. The [io.js build team](https://github.com/nodejs/build) is able to provide this access to individuals authorized by the TC.
Release builds require manual promotion by an individual with SSH access to the server as the _dist_ user. The [Node.js build team](https://github.com/nodejs/build) is able to provide this access to individuals authorized by the TC.
The key you use may be a child/subkey of an existing key.
Additionally, full GPG key fingerprints for individuals authorized to release should be listed in the io.js GitHub README.md file.
Additionally, full GPG key fingerprints for individuals authorized to release should be listed in the Node.js GitHub README.md file.
## How to create a release
@ -56,7 +56,7 @@ Run a **[iojs+any-pr+multi](https://jenkins-iojs.nodesource.com/job/iojs+any-pr+
### 2. Produce a Nightly Build _(optional)_
If there is a reason to produce a test release for the purpose of having others try out installers or specifics of builds, produce a nightly build using **[iojs+release](https://jenkins-iojs.nodesource.com/job/iojs+release/)** and wait for it to drop in <http://iojs.org/download/nightly/>. Follow the directions and enter a proper length commit sha, a date string and select "nightly" for "disttype".
If there is a reason to produce a test release for the purpose of having others try out installers or specifics of builds, produce a nightly build using **[iojs+release](https://jenkins-iojs.nodesource.com/job/iojs+release/)** and wait for it to drop in <http://nodejs.org/download/nightly/>. Follow the directions and enter a proper length commit sha, a date string and select "nightly" for "disttype".
This is particularly recommended if there has been recent work relating to the OS X or Windows installers as they are not tested in any way by CI.
@ -88,7 +88,7 @@ The _CHANGELOG.md_ entry should take the following form:
### Known issues
See https://github.com/nodejs/io.js/labels/confirmed-bug for complete and current list of known issues.
See https://github.com/nodejs/node/labels/confirmed-bug for complete and current list of known issues.
* Include this section if there are any known problems with this release
* Scan GitHub for unresolved problems that users may need to be aware of
@ -132,7 +132,7 @@ The _CHANGELOG.md_ and _src/node_version.h_ changes should be the final commit t
When committing these to git, use the following message format:
```
YYYY-MM-DD io.js vx.y.z Release
YYYY-MM-DD node.js vx.y.z Release
Notable changes:
@ -141,7 +141,7 @@ Notable changes:
### 6. Push to GitHub
Note that it is not essential that the release builds be created from the io.js repository, they may be created from your own fork if you desire. It is preferable, but not essential that the commits remain the same between that used to build and the tagged commit in the io.js repository.
Note that it is not essential that the release builds be created from the Node.js repository, they may be created from your own fork if you desire. It is preferable, but not essential that the commits remain the same between that used to build and the tagged commit in the Node.js repository.
### 7. Produce Release Builds
@ -160,7 +160,7 @@ Note that you do not have to wait for the ARM builds if they are take longer tha
Tag the release as <b><code>vx.y.z</code></b> and sign **using the same GPG key that will be used to sign SHASUMS256.txt**.
```
$ git tag <vx.y.z><commit-sha> -sm 'YYYY-MM-DD io.js vz.y.x Release'
$ git tag <vx.y.z><commit-sha> -sm 'YYYY-MM-DD node.js vz.y.x Release'
```
Push the tag to GitHub.
@ -210,13 +210,13 @@ If you didn't wait for ARM builds in the previous step before promoting the rele
### 11. Check the Release
Your release should be available at <https://iojs.org/dist/vx.y.z/> and also <https://iojs.org/dist/latest/>. Check that the appropriate files are in place, you may also want to check that the binaries are working as appropriate and have the right internal version strings. Check that the API docs are available at <https://iojs.org/api/>. Check that the release catalog files are correct at <https://iojs.org/dist/index.tab> and <https://iojs.org/dist/index.json>.
Your release should be available at <https://nodejs.org/dist/vx.y.z/> and also <https://nodejs.org/dist/latest/>. Check that the appropriate files are in place, you may also want to check that the binaries are working as appropriate and have the right internal version strings. Check that the API docs are available at <https://nodejs.org/api/>. Check that the release catalog files are correct at <https://nodejs.org/dist/index.tab> and <https://nodejs.org/dist/index.json>.
### 12. Announce
The iojs.org website will automatically rebuild and include the new version. You simply need to announce the build, preferably via twitter with a message such as:
The nodejs.org website will automatically rebuild and include the new version. You simply need to announce the build, preferably via twitter with a message such as:
> v2.3.2 of @official_iojs is out @ https://iojs.org/dist/latest/ changelog @ https://github.com/nodejs/io.js/blob/master/CHANGELOG.md#2015-07-01-version-232-rvagg … something here about notable changes
> v2.3.2 of @official_iojs is out @ https://nodejs.org/dist/latest/ changelog @ https://github.com/nodejs/node/blob/master/CHANGELOG.md#2015-07-01-version-232-rvagg … something here about notable changes
<!-- See https://msdn.microsoft.com/en-us/goglobal/bb964664.aspx -->
<String Id="LocaleId">1031</String>
<String Id="WelcomeDlgDescription">Dieser Installationsassistent wird [ProductName] auf Ihrem Computer installieren.

WARNUNG: Wenn Sie von [ProductName] v1.0.0 oder v1.0.1 aus updaten wollen, müssen Sie diese Versionen zuerst manuell deinstallieren.</String>
<String Id="WelcomeDlgDescription">Dieser Installationsassistent wird [ProductName] auf Ihrem Computer installieren.

WARNUNG: Wenn Sie von io.js v1.0.0 oder v1.0.1 aus updaten wollen, müssen Sie diese Versionen zuerst manuell deinstallieren.</String>
<String Id="InstallDirDlgDescription">Wählen Sie einen anderen Installationsort oder klicken Sie auf Weiter zum installieren.</String>
<String Id="MajorUpgrade_DowngradeErrorMessage">Eine neuere Version von [ProductName] ist bereits installiert. Der Installationsassistent wird jetzt geschlossen.</String>
<!-- References like [ProductName] or $(var.ProductName) don't seem to work in Title attributes -->
<String Id="EnvironmentPathNpmModules_Description">Fügt globale durch npm installierte Module zur PATH-Umgebungsvariable hinzu. Diese Option funktioniert nur für den aktuellen Benutzer, andere Benutzer müssen ihre PATH-Umgebungsvariable selbst manuell aktualisieren.</String>
<!-- References like [ProductName] are not resolved for Property tags -->
<String Id="WIXUI_EXITDIALOGOPTIONALTEXT">io.js wurde erfolgreich installiert.</String>
<String Id="WIXUI_EXITDIALOGOPTIONALTEXT">Node.js wurde erfolgreich installiert.</String>
<!-- See https://msdn.microsoft.com/en-us/goglobal/bb964664.aspx -->
<String Id="LocaleId">1033</String>
<String Id="WelcomeDlgDescription">The Setup Wizard will install [ProductName] on your computer.

WARNING: if you're upgrading from [ProductName] v1.0.0 or v1.0.1, you must first uninstall these versions manually.</String>
<String Id="WelcomeDlgDescription">The Setup Wizard will install [ProductName] on your computer.

WARNING: if you're upgrading from io.js v1.0.0 or v1.0.1, you must first uninstall these versions manually.</String>
<String Id="InstallDirDlgDescription">Choose a custom location or click Next to install.</String>
<String Id="MajorUpgrade_DowngradeErrorMessage">A later version of [ProductName] is already installed. Setup will now exit.</String>
<!-- References like [ProductName] or $(var.ProductName) don't seem to work in Title attributes -->
<String Id="NodeRuntime_Description">Install the core [ProductName] runtime (node.exe).</String>
<String Id="NodeAlias_Title">Alias node to iojs</String>
<String Id="NodeAlias_Description">Create node.exe as an alias for iojs.exe.</String>
@ -30,12 +30,12 @@
<String Id="EnvironmentPath_Title">Add to PATH</String>
<String Id="EnvironmentPath_Description">Add [ProductName], npm, and modules that were globally installed by npm to the PATH environment variable.</String>
<String Id="EnvironmentPathNode_Title">io.js and npm</String>
<String Id="EnvironmentPathNode_Title">Node.js and npm</String>
<String Id="EnvironmentPathNode_Description">Add [ProductName] and npm (if installed) to the PATH environment variable.</String>
<String Id="EnvironmentPathNpmModules_Description">Add modules that are installed globally by npm to the PATH environment variable. This option works for the current user only; other users need to update their PATH manually.</String>
<!-- References like [ProductName] are not resolved for Property tags -->
<String Id="WIXUI_EXITDIALOGOPTIONALTEXT">io.js has been successfully installed.</String>
<String Id="WIXUI_EXITDIALOGOPTIONALTEXT">Node.js has been successfully installed.</String>
\f0\fs26 \cf0 This package will install io.js {iojsversion} and npm {npmversion} into /usr/local/. The binary /usr/local/bin/iojs will also be symlinked as /usr/local/bin/node.}]]></resource>
\f0\fs26 \cf0 This package will install Node.js {iojsversion} and npm {npmversion} into /usr/local/. The binary /usr/local/bin/iojs will also be symlinked as /usr/local/bin/node.}]]></resource>
cjihrig
9 years ago