Commit 9ef4dc4f authored by Jérémy Lal's avatar Jérémy Lal

New upstream version 8.4.0~dfsg

parent cf646cde

Too many changes to show.

To preserve performance only 1000 of 1000+ files are displayed.

......@@ -26,24 +26,26 @@ Support is divided into three tiers:
the broader community.
* **Tier 2**: Full test coverage but more limited maintenance,
often provided by the vendor of the platform.
* **Experimental**: Known to compile but not necessarily reliably or with
a full passing test suite. These are often working to be promoted to Tier
2 but are not quite ready. There is at least one individual actively
providing maintenance and the team is striving to broaden quality and
reliability of support.
* **Experimental**: May not compile reliably or test suite may not pass.
These are often working to be promoted to Tier 2 but are not quite ready.
There is at least one individual actively providing maintenance and the team
is striving to broaden quality and reliability of support.
### Supported platforms
The community does not build or test against end of life distributions (EoL).
Thus we do not recommend that you use Node on end of life or unsupported platforms
in production.
| System | Support type | Version | Architectures | Notes |
|--------------|--------------|----------------------------------|----------------------|------------------|
| GNU/Linux | Tier 1 | kernel >= 2.6.18, glibc >= 2.5 | x86, x64, arm, arm64 | |
| GNU/Linux | Tier 1 | kernel >= 2.6.32, glibc >= 2.12 | x86, x64, arm, arm64 | |
| macOS | Tier 1 | >= 10.10 | x64 | |
| Windows | Tier 1 | >= Windows 7 or >= Windows2008R2 | x86, x64 | |
| SmartOS | Tier 2 | >= 14 < 16.4 | x86, x64 | see note1 |
| Windows | Tier 1 | >= Windows 7 / 2008 R2 | x86, x64 | vs2015 or vs2017 |
| SmartOS | Tier 2 | >= 15 < 16.4 | x86, x64 | see note1 |
| FreeBSD | Tier 2 | >= 10 | x64 | |
| GNU/Linux | Tier 2 | kernel >= 4.2.0, glibc >= 2.19 | ppc64be | |
| GNU/Linux | Tier 2 | kernel >= 3.13.0, glibc >= 2.19 | ppc64le | |
| AIX | Tier 2 | >= 6.1 TL09 | ppc64be | |
| GNU/Linux | Tier 2 | kernel >= 3.13.0, glibc >= 2.19 | ppc64le >=power8 | |
| AIX | Tier 2 | >= 7.1 TL04 | ppc64be >=power7 | |
| GNU/Linux | Tier 2 | kernel >= 3.10, glibc >= 2.17 | s390x | |
| macOS | Experimental | >= 10.8 < 10.10 | x64 | no test coverage |
| Linux (musl) | Experimental | musl >= 1.0 | x64 | |
......@@ -63,8 +65,8 @@ Depending on host platform, the selection of toolchains may vary.
#### Unix
* GCC 4.8 or newer
* Clang 3.4 or newer
* GCC 4.9.4 or newer
* Clang 3.4.2 or newer
#### Windows
......@@ -78,25 +80,24 @@ Depending on host platform, the selection of toolchains may vary.
Prerequisites:
* `gcc` and `g++` 4.8.5 or newer, or
* `clang` and `clang++` 3.4 or newer
* `gcc` and `g++` 4.9.4 or newer, or
* `clang` and `clang++` 3.4.2 or newer (macOS: latest Xcode Command Line Tools)
* Python 2.6 or 2.7
* GNU Make 3.81 or newer
On macOS, you will also need:
* [Xcode](https://developer.apple.com/xcode/download/)
- You also need to install the `Command Line Tools` via Xcode. You can find
this under the menu `Xcode -> Preferences -> Downloads`
- This step will install `gcc` and the related toolchain containing `make`
* After building, you may want to setup [firewall rules](tools/macosx-firewall.sh)
On macOS you will need to install the `Xcode Command Line Tools` by running
`xcode-select --install`. Alternatively, if you already have the full Xcode
installed, you can find them under the menu `Xcode -> Open Developer Tool ->
More Developer Tools...`. This step will install `clang`, `clang++`, and
`make`.
* You may want to setup [firewall rules](tools/macosx-firewall.sh)
to avoid popups asking to accept incoming network connections when running tests:
```console
$ sudo ./tools/macosx-firewall.sh
```
Running this script will add rules for the executable `node` in the out
directory and the symbolic `node` link in the projects root directory.
directory and the symbolic `node` link in the project's root directory.
On FreeBSD and OpenBSD, you may also need:
* libexecinfo
......@@ -125,15 +126,6 @@ To run the tests:
$ make test
```
To run the npm test suite:
*note: to run the suite on node v4 or earlier you must first*
*run `make install`*
```console
$ make test-npm
```
To build the documentation:
This will build Node.js first (if necessary) and then use it to build the docs:
......@@ -177,18 +169,20 @@ Prerequisites:
* [Visual Studio 2015 Update 3](https://www.visualstudio.com/), all editions
including the Community edition (remember to select
"Common Tools for Visual C++ 2015" feature during installation).
* [Visual Studio 2017](https://www.visualstudio.com/downloads/), any edition (including the Build Tools SKU).
**Required Components:** "MSbuild", "VC++ 2017 v141 toolset" and one of the Windows SDKs (10 or 8.1).
* Basic Unix tools required for some tests,
[Git for Windows](http://git-scm.com/download/win) includes Git Bash
and tools which can be included in the global `PATH`.
```console
> .\vcbuild nosign
> .\vcbuild
```
To run the tests:
```console
> .\vcbuild nosign test
> .\vcbuild test
```
To test if Node.js was built correctly:
......@@ -206,9 +200,9 @@ in the current continuous integration environment. The participation of people
dedicated and determined to improve Android building, testing, and support is
encouraged.
Be sure you have downloaded and extracted [Android NDK]
(https://developer.android.com/tools/sdk/ndk/index.html)
before in a folder. Then run:
Be sure you have downloaded and extracted
[Android NDK](https://developer.android.com/tools/sdk/ndk/index.html) before in
a folder. Then run:
```console
$ ./android-configure /path/to/your/android-ndk
......@@ -246,7 +240,7 @@ $ ./configure --with-intl=full-icu --download=all
##### Windows:
```console
> .\vcbuild nosign full-icu download-all
> .\vcbuild full-icu download-all
```
#### Building without Intl support
......@@ -263,7 +257,7 @@ $ ./configure --without-intl
##### Windows:
```console
> .\vcbuild nosign without-intl
> .\vcbuild without-intl
```
#### Use existing installed ICU (Unix / macOS only):
......@@ -306,7 +300,7 @@ First unpack latest ICU to `deps/icu`
as `deps/icu` (You'll have: `deps/icu/source/...`)
```console
> .\vcbuild nosign full-icu
> .\vcbuild full-icu
```
## Building Node.js with FIPS-compliant OpenSSL
......@@ -350,6 +344,6 @@ and [user guide](https://openssl.org/docs/fips/UserGuide-2.0.pdf).
6. Get into Node.js checkout folder
7. `./configure --openssl-fips=/path/to/openssl-fips/installdir`
For example on ubuntu 12 the installation directory was
/usr/local/ssl/fips-2.0
`/usr/local/ssl/fips-2.0`
8. Build Node.js with `make -j`
9. Verify with `node -p "process.versions.openssl"` (`1.0.2a-fips`)
9. Verify with `node -p "process.versions.openssl"` (for example `1.0.2a-fips`)
This diff is collapsed.
......@@ -4,6 +4,7 @@
* [Issues and Pull Requests](#issues-and-pull-requests)
* [Accepting Modifications](#accepting-modifications)
- [Useful CI Jobs](#useful-ci-jobs)
- [Internal vs. Public API](#internal-vs-public-api)
- [Breaking Changes](#breaking-changes)
- [Deprecations](#deprecations)
......@@ -87,6 +88,31 @@ All pull requests that modify executable code should be subjected to
continuous integration tests on the
[project CI server](https://ci.nodejs.org/).
#### Useful CI Jobs
* [`node-test-pull-request`](https://ci.nodejs.org/job/node-test-pull-request/)
is the standard CI run we do to check Pull Requests. It triggers `node-test-commit`,
which runs the `build-ci` and `test-ci` targets on all supported platforms.
* [`node-test-linter`](https://ci.nodejs.org/job/node-test-linter/)
only runs the linter targets, which is useful for changes that only affect comments
or documentation.
* [`citgm-smoker`](https://ci.nodejs.org/job/citgm-smoker/)
uses [`CitGM`](https://github.com/nodejs/citgm) to allow you to run `npm install && npm test`
on a large selection of common modules. This is useful to check whether a
change will cause breakage in the ecosystem. To test Node.JS ABI changes
you can run [`citgm-abi-smoker`](https://ci.nodejs.org/job/citgm-abi-smoker/).
* [`node-stress-single-test`](https://ci.nodejs.org/job/node-stress-single-test/)
is designed to allow one to run a group of tests over and over on a specific
platform to confirm that the test is reliable.
* [`node-test-commit-v8-linux`](https://ci.nodejs.org/job/node-test-commit-v8-linux/)
is designed to allow validation of changes to the copy of V8 in the Node.js
tree by running the standard V8 tests. It should be run whenever the
level of V8 within Node.js is updated or new patches are floated on V8.
### Internal vs. Public API
Due to the nature of the JavaScript language, it can often be difficult to
......@@ -230,6 +256,13 @@ not can often be based on many complex factors that are not easily codified. It
is also possible that the breaking commit can be labeled retroactively as a
semver-major change that will not be backported to Current or LTS branches.
##### Reverting commits
Commits are reverted with `git revert <HASH>`, or `git revert <FROM>..<TO>` for
multiple commits. Commit metadata and the reason for the revert should be
appended. Commit message rules about line length and subsystem can be ignored.
A Pull Request should be raised and approved like any other change.
### Deprecations
Deprecation refers to the identification of Public APIs that should no longer
......
......@@ -2,43 +2,35 @@
## 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.](https://github.com/nodejs/TSC/blob/master/CODE_OF_CONDUCT.md)
Please read the
[Code of Conduct](https://github.com/nodejs/TSC/blob/master/CODE_OF_CONDUCT.md)
which explains the minimum behavior expectations for Node.js contributors.
## Issue Contributions
When opening new issues or commenting on existing issues on this repository
please make sure discussions are related to concrete technical issues with the
Node.js software.
When opening issues or commenting on existing issues, please make sure
discussions are related to concrete technical issues with Node.js.
For general help using Node.js, please file an issue at the
* For general help using Node.js, please file an issue at the
[Node.js help repository](https://github.com/nodejs/help/issues).
Discussion of non-technical topics including subjects like intellectual
property, trademark, and high level project questions should move to the
[Technical Steering Committee (TSC)](https://github.com/nodejs/TSC/issues)
instead.
* Discussion of non-technical topics (such as intellectual property and
trademark) should use the
[Technical Steering Committee (TSC) repository](https://github.com/nodejs/TSC/issues).
## Code Contributions
The Node.js project has an open governance model and welcomes new contributors.
Individuals making significant and valuable contributions are made
_Collaborators_ and given commit-access to the project. See the
[GOVERNANCE.md](./GOVERNANCE.md) document for more information about how this
works.
This document will guide you through the contribution process.
This section will guide you through the contribution process.
### Step 1: Fork
Fork the project [on GitHub](https://github.com/nodejs/node) and check out your
copy locally.
Fork the project [on GitHub](https://github.com/nodejs/node) and clone your fork
locally.
```text
$ git clone git@github.com:username/node.git
$ cd node
$ git remote add upstream git://github.com/nodejs/node.git
$ git remote add upstream https://github.com/nodejs/node.git
```
#### Which branch?
......@@ -49,24 +41,18 @@ and built upon.
#### Dependencies