nodejs · rvagg · Oct 28, 2015 · Oct 25, 2015 · Oct 20, 2015 · Oct 21, 2015
diff --git a/.eslintrc b/.eslintrc
@@ -70,6 +70,11 @@ rules:
   # require space after keywords, eg 'for (..)'
   space-after-keywords: 2
 
+  # ECMAScript 6
+  # list: http://eslint.org/docs/rules/#ecmascript-6
+  ## Suggest using 'const' wherever possible
+  prefer-const: 2
+
   # Strict Mode
   # list: https://github.com/eslint/eslint/tree/master/docs/rules#strict-mode
   ## 'use strict' on top
@@ -82,6 +87,8 @@ rules:
 
   # Custom rules in tools/eslint-rules
   require-buffer: 2
+  new-with-error: [2, "Error", "RangeError", "TypeError", "SyntaxError", "ReferenceError"]
+
 
 # Global scoped method and vars
 globals:

diff --git a/.gitignore b/.gitignore
@@ -24,7 +24,7 @@ icu_config.gypi
 
 # various stuff that VC++ produces/uses
 Debug/
-!node_modules/debug/
+!deps/npm/node_modules/node-gyp/node_modules/path-array/node_modules/array-index/node_modules/debug
 !deps/v8/src/debug/
 Release/
 !doc/blog/**
@@ -44,6 +44,7 @@ ipch/
 
 /config.mk
 /config.gypi
+/config_fips.gypi
 *-nodegyp*
 /gyp-mac-tool
 /dist-osx

diff --git a/CHANGELOG.md b/CHANGELOG.md
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
@@ -45,21 +51,21 @@ and built upon.
 The rules for the master branch are less strict; consult the
 [stability index](./doc/api/documentation.markdown#stability-index) for details.
 
-In a nutshell, modules are at varying levels of API stability.  Bug fixes are
+In a nutshell, modules are at varying levels of API stability. Bug fixes are
 always welcome but API or behavioral changes to modules at stability level 3
 (Locked) are off-limits.
 
 #### Dependencies
 
 Node.js has several bundled dependencies in the *deps/* and the *tools/*
-directories that are not part of the project proper.  Any changes to files
+directories that are not part of the project proper. Any changes to files
 in those directories or its subdirectories should be sent to their respective
-projects.  Do not send your patch to us, we cannot accept it.
+projects. Do not send your patch to us, we cannot accept it.
 
 In case of doubt, open an issue in the
 [issue tracker](https://github.com/nodejs/node/issues/) or contact one of the
 [project Collaborators](https://github.com/nodejs/node/#current-project-team-members).
-([IRC](http://webchat.freenode.net/?channels=io.js) is often the best medium.) Especially do so if you plan to work on something big.  Nothing is more
+([IRC](http://webchat.freenode.net/?channels=io.js) is often the best medium.) Especially do so if you plan to work on something big. Nothing is more
 frustrating than seeing your hard work go to waste because your vision
 does not align with the project team.
 
@@ -81,8 +87,8 @@ $ git config --global user.name "J. Random User"
 $ git config --global user.email "j.random.user@example.com"
 ```
 
-Writing good commit logs is important.  A commit log should describe what
-changed and why.  Follow these guidelines when writing one:
+Writing good commit logs is important. A commit log should describe what
+changed and why. Follow these guidelines when writing one:
 
 1. The first line should be 50 characters or less and contain a short
    description of the change prefixed with the name of the changed
@@ -124,15 +130,15 @@ $ git rebase upstream/master
 
 ### Step 5: Test
 
-Bug fixes and features **should come with tests**.  Add your tests in the
-test/parallel/ directory.  Look at other tests to see how they should be
+Bug fixes and features **should come with tests**. Add your tests in the
+test/parallel/ directory. Look at other tests to see how they should be
 structured (license boilerplate, common includes, etc.).
 
 ```text
 $ ./configure && make -j8 test
 ```
 
-Make sure the linter is happy and that all tests pass.  Please, do not submit
+Make sure the linter is happy and that all tests pass. Please, do not submit
 patches that fail either check.
 
 If you are updating tests and just want to run a single test to check it, you
@@ -160,9 +166,9 @@ $ git push origin my-feature-branch
 Go to https://github.com/yourusername/node and select your feature branch.
 Click the 'Pull Request' button and fill out the form.
 
-Pull requests are usually reviewed within a few days.  If there are comments
+Pull requests are usually reviewed within a few days. If there are comments
 to address, apply your changes in a separate commit and push that to your
-feature branch.  Post a comment in the pull request afterwards; GitHub does
+feature branch. Post a comment in the pull request afterwards; GitHub does
 not send out notifications when you add commits.
 
 
@@ -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/Makefile b/Makefile
@@ -74,7 +74,7 @@ clean:
 
 distclean:
 	-rm -rf out
-	-rm -f config.gypi icu_config.gypi
+	-rm -f config.gypi icu_config.gypi config_fips.gypi
 	-rm -f config.mk
 	-rm -rf $(NODE_EXE) $(NODE_G_EXE)
 	-rm -rf node_modules