nodejs · vkurchatkin · Nov 6, 2015 · Aug 28, 2015 · Sep 30, 2015 · Oct 13, 2015
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -1,6 +1,6 @@
 # Node.js ChangeLog
 
-## 2015-10-29, Version 4.2.2 'Argon' (LTS), @jasnell
+## 2015-11-03, Version 4.2.2 'Argon' (LTS), @jasnell
 
 ### Notable changes
 
@@ -24,7 +24,6 @@ This is an LTS maintenance release that addresses a number of issues:
 
 ### Known issues
 
-* Some problems with unreferenced timers running during `beforeExit` are still to be resolved. See [#1264](https://github.com/nodejs/node/issues/1264).
 * Surrogate pair in REPL can freeze terminal. [#690](https://github.com/nodejs/node/issues/690)
 * Calling `dns.setServers()` while a DNS query is in progress can cause the process to crash on a failed assertion. [#894](https://github.com/nodejs/node/issues/894)
 * `url.resolve` may transfer the auth portion of the url when resolving between two full hosts, see [#1435](https://github.com/nodejs/node/issues/1435).

diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
@@ -0,0 +1,38 @@
+## Code of Conduct
+
+This Code of Conduct is adapted from [Rust's wonderful
+CoC](http://www.rust-lang.org/conduct.html).
+
+* We are committed to providing a friendly, safe and welcoming
+  environment for all, regardless of gender, sexual orientation,
+  disability, ethnicity, religion, or similar personal characteristic.
+* Please avoid using overtly sexual nicknames or other nicknames that
+  might detract from a friendly, safe and welcoming environment for
+  all.
+* Please be kind and courteous. There's no need to be mean or rude.
+* Respect that some individuals and cultures consider the casual use of
+  profanity offensive and off-putting.
+* Respect that people have differences of opinion and that every
+  design or implementation choice carries a trade-off and numerous
+  costs. There is seldom a right answer.
+* Please keep unstructured critique to a minimum. If you have solid
+  ideas you want to experiment with, make a fork and see how it works.
+* We will exclude you from interaction if you insult, demean or harass
+  anyone. That is not welcome behavior. We interpret the term
+  "harassment" as including the definition in the [Citizen Code of
+  Conduct](http://citizencodeofconduct.org/); if you have any lack of
+  clarity about what might be included in that concept, please read
+  their definition. In particular, we don't tolerate behavior that
+  excludes people in socially marginalized groups.
+* Private harassment is also unacceptable. No matter who you are, if
+  you feel you have been or are being harassed or made uncomfortable
+  by a community member, please contact one of the channel ops or any
+  of the TSC members immediately with a capture (log, photo, email) of
+  the harassment if possible. Whether you're a regular contributor or
+  a newcomer, we care about making this community a safe place for you
+  and we've got your back.
+* Likewise any spamming, trolling, flaming, baiting or other
+  attention-stealing behavior is not welcome.
+* Avoid the use of personal pronouns in code comments or
+  documentation. There is no need to address persons when explaining
+  code (e.g. "When the developer").
diff --git a/COLLABORATOR_GUIDE.md b/COLLABORATOR_GUIDE.md
@@ -8,6 +8,7 @@
 * [Landing Pull Requests](#landing-pull-requests)
  - [Technical HOWTO](#technical-howto)
  - [I Just Made a Mistake](#i-just-made-a-mistake)
+ - [Long Term Support](#long-term-support)
 
 This document contains information for Collaborators of the Node.js
 project regarding maintaining the code, documentation and issues.
@@ -227,3 +228,93 @@ messages. However, you are only allowed to force push to any Node.js
 branch within 10 minutes from your original push. If someone else
 pushes to the branch or the 10 minute period passes, consider the
 commit final.
+
+### Long Term Support
+
+#### What is LTS?
+
+Long Term Support (often referred to as *LTS*) guarantees application developers
+a 30 month support cycle with specific versions of Node.js.
+
+You can find more information [in the full LTS plan](https://github.com/nodejs/lts#lts-plan).
+
+#### How does LTS work?
+
+Once a stable branch enters LTS, changes in that branch are limited to bug
+fixes, security updates, possible npm updates, documentation updates, and
+certain performance improvements that can be demonstrated to not break existing
+applications. Semver-minor changes are only permitted if required for bug fixes
+and then only on a case-by-case basis with LTS WG and possibly Core Technical
+Committee (CTC) review. Semver-major changes are permitted only if required for
+security related fixes.
+
+Once a stable branch moves into Maintenance mode, only **critical** bugs,
+**critical** security fixes, and documentation updates will be permitted.
+
+#### Landing semver-minor commits in LTS
+
+The default policy is to not land semver-minor or higher commits in any LTS
+branch. However, the LTS WG or CTC can evaluate any individual semver-minor
+commit and decide whether a special exception ought to be made. It is
+expected that such exceptions would be evaluated, in part, on the scope
+and impact of the changes on the code, the risk to ecosystem stability
+incurred by accepting the change, and the expected benefit that landing the
+commit will have for the ecosystem.
+
+Any collaborator who feels a semver-minor commit should be landed in an LTS
+branch should attach the `lts-agenda` label to the pull request. The LTS WG
+will discuss the issue and, if necessary, will escalate the issue up to the
+CTC for further discussion.
+
+#### How are LTS Branches Managed?
+
+There are currently three LTS branches: `v4.x`, `v0.10`, and `v0.12`. Each
+of these is paired with a "staging" branch: `v4.x-staging`, `v0.10-staging`,
+and `v0.12-staging`.
+
+As commits land in `master`, they are cherry-picked back to each staging
+branch as appropriate. If the commit applies only to the LTS branch, the
+PR must be opened against the *staging* branch. Commits are selectively
+pulled from the staging branch into the LTS branch only when a release is
+being prepared and may be pulled into the LTS branch in a different order
+than they were landed in staging.
+
+Any collaborator may land commits into a staging branch, but only the release
+team should land commits into the LTS branch while preparing a new
+LTS release.
+
+#### How can I help?
+
+When you send your pull request, consider including information about
+whether your change is breaking. If you think your patch can be backported,
+please feel free to include that information in the PR thread.
+
+Several LTS related issue and PR labels have been provided:
+
+* `lts-watch-v4.x` - tells the LTS WG that the issue/PR needs to be considered
+  for landing in the `v4.x-staging` branch.
+* `lts-watch-v0.10` - tells the LTS WG that the issue/PR needs to be considered
+  for landing in the `v0.10-staging` branch.
+* `lts-watch-v0.12` - tells the LTS WG that the issue/PR needs to be considered
+  for landing in the `v0.12-staging` branch.
+* `land-on-v4.x` - tells the release team that the commit should be landed
+  in a future v4.x release
+* `land-on-v0.10` - tells the release team that the commit should be landed
+  in a future v0.10 release
+* `land-on-v0.12` - tells the release team that the commit should be landed
+  in a future v0.12 release
+
+Any collaborator can attach these labels to any PR/issue. As commits are
+landed into the staging branches, the `lts-watch-` label will be removed.
+Likewise, as commits are landed in a LTS release, the `land-on-` label will
+be removed.
+
+Collaborators are encouraged to help the LTS WG by attaching the appropriate
+`lts-watch-` label to any PR that may impact an LTS release.
+
+#### How is an LTS release cut?
+
+When the LTS working group determines that a new LTS release is required,
+selected commits will be picked from the staging branch to be included in the
+release. This process of making a release will be a collaboration between the
+LTS working group and the Release team.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,5 +1,11 @@
 # Contributing to Node.js
 
+## Code of Conduct
+
+The Code of Conduct explains the *bare minimum* behavior
+expectations the Node Foundation requires of its contributors.
+[Please read it before participating.](./CODE_OF_CONDUCT.md)
+
 ## Issue Contributions
 
 When opening new issues or commenting on existing issues on this repository
@@ -181,41 +187,3 @@ By making a contribution to this project, I certify that:
   different license), as indicated in the file; or
 * (c) The contribution was provided directly to me by some other
   person who certified (a), (b) or (c) and I have not modified it.
-
-
-## Code of Conduct
-
-This Code of Conduct is adapted from [Rust's wonderful
-CoC](http://www.rust-lang.org/conduct.html).
-
-* We are committed to providing a friendly, safe and welcoming
-  environment for all, regardless of gender, sexual orientation,
-  disability, ethnicity, religion, or similar personal characteristic.
-* Please avoid using overtly sexual nicknames or other nicknames that
-  might detract from a friendly, safe and welcoming environment for
-  all.
-* Please be kind and courteous. There's no need to be mean or rude.
-* Respect that people have differences of opinion and that every
-  design or implementation choice carries a trade-off and numerous
-  costs. There is seldom a right answer.
-* Please keep unstructured critique to a minimum. If you have solid
-  ideas you want to experiment with, make a fork and see how it works.
-* We will exclude you from interaction if you insult, demean or harass
-  anyone.  That is not welcome behavior. We interpret the term
-  "harassment" as including the definition in the [Citizen Code of
-  Conduct](http://citizencodeofconduct.org/); if you have any lack of
-  clarity about what might be included in that concept, please read
-  their definition. In particular, we don't tolerate behavior that
-  excludes people in socially marginalized groups.
-* Private harassment is also unacceptable. No matter who you are, if
-  you feel you have been or are being harassed or made uncomfortable
-  by a community member, please contact one of the channel ops or any
-  of the TC members immediately with a capture (log, photo, email) of
-  the harassment if possible.  Whether you're a regular contributor or
-  a newcomer, we care about making this community a safe place for you
-  and we've got your back.
-* Likewise any spamming, trolling, flaming, baiting or other
-  attention-stealing behavior is not welcome.
-* Avoid the use of personal pronouns in code comments or
-  documentation. There is no need to address persons when explaining
-  code (e.g. "When the developer")
diff --git a/README.md b/README.md
@@ -1,38 +1,69 @@
-
 Node.js
-=====
+=======
 
 [![Gitter](https://badges.gitter.im/Join Chat.svg)](https://gitter.im/nodejs/node?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
 
-This repository began as a GitHub fork of
-[joyent/node](https://github.com/joyent/node).
-
-Node.js contributions, releases, and contributorship are under an
-[open governance model](./GOVERNANCE.md).
-We intend to land, with increasing regularity, releases which are
-compatible with the npm ecosystem that has been built to date for
-Node.js.
+The Node.js project is supported by the
+[Node.js Foundation](https://nodejs.org/en/foundation/). Contributions,
+policies and releases are managed under an
+[open governance model](./GOVERNANCE.md). We are also bound by a
+[Code of Conduct](./CODE_OF_CONDUCT.md).
+
+If you need help using or installing Node.js, please use the
+[nodejs/help](https://github.com/nodejs/help) issue tracker.
+
+## Release Types
+
+The Node.js project maintains multiple types of releases:
+
+* **Stable**: Released from active development branches of this repository,
+  versioned by [SemVer](http://semver.org/) and signed by a member of the
+  [Release Team](#release-team).
+  Code for Stable releases is organized in this repository by major version
+  number, For example: [v4.x](https://github.com/nodejs/node/tree/v4.x).
+  The major version number of Stable releases will increment every 6 months
+  allowing for breaking changes to be introduced. This happens in April and
+  October every year. Stable release lines beginning in October each year have
+  a maximum support life of 8 months. Stable release lines beginning in April
+  each year will convert to LTS (see below) after 6 months and receive further
+  support for 30 months.
+* **LTS**: Releases that receive Long-term Support, with a focus on stability
+  and security. Every second Stable release line (major version) will become an
+  LTS line and receive 18 months of _Active LTS_ support and a further 12
+  months of _Maintenance_. LTS release lines are given alphabetically
+  ordered codenames, begining with v4 Argon. LTS releases are less frequent
+  and will attempt to maintain consistent major and minor version numbers,
+  only incrementing patch version numbers. There are no breaking changes or
+  feature additions, except in some special circumstances. More information
+  can be found in the [LTS README](https://github.com/nodejs/LTS/).
+* **Nightly**: Versions of code in this repository on the current Stable
+  branch, automatically built every 24-hours where changes exist. Use with
+  caution.
 
 ## Download
 
 Binaries, installers, and source tarballs are available at
 <https://nodejs.org>.
 
-**Releases** are available at <https://nodejs.org/dist/>, listed under
-their version string. The <https://nodejs.org/dist/latest/> symlink
-will point to the latest release directory.
+**Stable** and **LTS** releases are available at
+<https://nodejs.org/download/release/>, listed under their version strings.
+The [latest](https://nodejs.org/download/release/latest/) directory is an
+alias for the latest Stable release. The latest LTS release from an LTS
+line is available in the form: latest-lts-_codename_. For example:
+<https://nodejs.org/download/release/latest-lts-argon>
 
 **Nightly** builds are available at
 <https://nodejs.org/download/nightly/>, listed under their version
 string which includes their date (in UTC time) and the commit SHA at
 the HEAD of the release.
 
 **API documentation** is available in each release and nightly
-directory under _docs_. <https://nodejs.org/api/> points to the latest version.
+directory under _docs_. <https://nodejs.org/api/> points to the API
+documentation of the latest stable version.
 
 ### Verifying Binaries
 
-Release and nightly download directories all contain a *SHASUM256.txt*
+Stable, LTS and Nightly download directories all contain a *SHASUM256.txt*
 file that lists the SHA checksums for each file available for
 download. To check that a downloaded file matches the checksum, run
 it through `sha256sum` with a command such as:
@@ -44,9 +75,9 @@ $ grep node-vx.y.z.tar.gz SHASUMS256.txt | sha256sum -c -
 _(Where "node-vx.y.z.tar.gz" is the name of the file you have
 downloaded)_
 
-Additionally, releases (not nightlies) have GPG signed copies of
-SHASUM256.txt files available as SHASUM256.txt.asc. You can use `gpg`
-to verify that the file has not been tampered with.
+Additionally, Stable and LTS releases (not Nightlies) have GPG signed
+copies of SHASUM256.txt files available as SHASUM256.txt.asc. You can use
+`gpg` to verify that the file has not been tampered with.
 
 To verify a SHASUM256.txt.asc, you will first need to import all of
 the GPG keys of individuals authorized to create releases. They are
@@ -226,6 +257,9 @@ Windows:
 $ pkg-config --modversion icu-i18n && ./configure --with-intl=system-icu
 ```
 
+If you are cross compiling, your `pkg-config` must be able to supply a path
+that works for both your host and target environments.
+
 #### Build with a specific ICU:
 
 You can find other ICU releases at
@@ -305,6 +339,7 @@ Instructions:
 
 ## Resources for Newcomers
 
+* [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md)
 * [CONTRIBUTING.md](./CONTRIBUTING.md)
 * [GOVERNANCE.md](./GOVERNANCE.md)
 * IRC:
@@ -316,7 +351,7 @@ Instructions:
 All security bugs in node.js are taken seriously and should be reported by
 emailing [email protected]. This will be delivered to a subset of the project
 team who handle security issues. Please don't disclose security bugs
-public until they have been handled by the security team.
+publicly until they have been handled by the security team.
 
 Your email will be acknowledged within 24 hours, and you’ll receive a more
 detailed response to your email within 48 hours indicating the next steps in
@@ -367,12 +402,15 @@ information about the governance of the Node.js project, see
 * [qard](https://github.com/qard) - **Stephen Belanger** &lt;[email protected]&gt;
 * [rlidwka](https://github.com/rlidwka) - **Alex Kocharin** &lt;[email protected]&gt;
 * [robertkowalski](https://github.com/robertkowalski) - **Robert Kowalski** &lt;[email protected]&gt;
+* [romankl](https://github.com/romankl) - **Roman Klauke** &lt;[email protected]&gt;
+* [saghul](https://github.com/saghul) - **Saúl Ibarra Corretgé** &lt;[email protected]&gt;
 * [sam-github](https://github.com/sam-github) - **Sam Roberts** &lt;[email protected]&gt;
 * [seishun](https://github.com/seishun) - **Nikolai Vavilov** &lt;[email protected]&gt;
 * [silverwind](https://github.com/silverwind) - **Roman Reiss** &lt;[email protected]&gt;
 * [srl295](https://github.com/srl295) - **Steven R Loomis** &lt;[email protected]&gt;
 * [targos](https://github.com/targos) - **Michaël Zasso** &lt;[email protected]&gt;
 * [tellnes](https://github.com/tellnes) - **Christian Tellnes** &lt;[email protected]&gt;
+* [thealphanerd](http://github.com/thealphanerd) - **Myles Borins** &lt;[email protected]&gt;
 * [thefourtheye](https://github.com/thefourtheye) - **Sakthipriyan Vairamani** &lt;[email protected]&gt;
 * [thlorenz](https://github.com/thlorenz) - **Thorsten Lorenz** &lt;[email protected]&gt;
 * [Trott](https://github.com/Trott) - **Rich Trott** &lt;[email protected]&gt;
@@ -387,7 +425,7 @@ maintaining the Node.js project.
 
 Releases of Node.js and io.js will be signed with one of the following GPG keys:
 
-* **Chris Dickinson** &lt;[email protected]&gt;: `9554F04D7259F04124DE6B476D5A82AC7E37093B`
+* **Chris Dickinson** &lt;[email protected]&gt; `9554F04D7259F04124DE6B476D5A82AC7E37093B`
 * **Colin Ihrig** &lt;[email protected]&gt; `94AE36675C464D64BAFA68DD7434390BDBE9B9C5`
 * **Sam Roberts** &lt;[email protected]&gt; `0034A06D9D9B0064CE8ADF6BF1747F4AD2306D93`
 * **Jeremiah Senkpiel** &lt;[email protected]&gt; `FD3A5288F042B6850C66B31F09FE44734EB7990E`