Commit 9581693c authored by Jérémy Lal's avatar Jérémy Lal

New upstream version 6.11.2~dfsg

parent 94c3c921
......@@ -26,14 +26,17 @@ 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 | |
......@@ -63,8 +66,8 @@ Depending on host platform, the selection of toolchains may vary.
#### Unix
* GCC 4.8 or newer
* Clang 3.4 or newer
* GCC 4.8.5 or newer
* Clang 3.4.2 or newer
#### Windows
......@@ -79,24 +82,23 @@ 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
* `clang` and `clang++` 3.4.2 or newer
* 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
......@@ -121,17 +123,8 @@ and not a newer version.
To run the tests:
```console
$ 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
$ make test
```
To build the documentation:
......@@ -206,9 +199,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
......@@ -350,6 +343,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`)
......@@ -26,7 +26,8 @@ release.
</tr>
<tr>
<td valign="top">
<b><a href="doc/changelogs/CHANGELOG_V6.md#6.11.1">6.11.1</a></b><br/>
<b><a href="doc/changelogs/CHANGELOG_V6.md#6.11.2">6.11.2</a></b><br/>
<a href="doc/changelogs/CHANGELOG_V6.md#6.11.1">6.11.1</a><br/>
<a href="doc/changelogs/CHANGELOG_V6.md#6.11.0">6.11.0</a><br/>
<a href="doc/changelogs/CHANGELOG_V6.md#6.10.3">6.10.3</a><br/>
<a href="doc/changelogs/CHANGELOG_V6.md#6.10.2">6.10.2</a><br/>
......
......@@ -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
......
......@@ -38,7 +38,7 @@ copy 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?
......@@ -182,7 +182,14 @@ If you are updating tests and just want to run a single test to check it, you
can use this syntax to run it exactly as the test harness would:
```text
$ python tools/test.py -v --mode=release parallel/test-stream2-transform
$ python tools/test.py -J --mode=release parallel/test-stream2-transform
```
If you want to check the other options, please refer to the help by using
the `--help` option
```text
$ python tools/test.py --help
```
You can run tests directly with node:
......
# Node.js Project Governance
## Core Technical Committee
The Node.js project is governed by a Core Technical Committee (CTC) which is
responsible for high-level guidance of the project.
The CTC has final authority over this project including:
* Technical direction
* Project governance and process (including this policy)
* Contribution policy
* GitHub repository hosting
* Conduct guidelines
* Maintaining the list of additional Collaborators
For the current list of CTC members, see the project
[README.md](./README.md#current-project-team-members).
The Node.js project is governed by its Collaborators, including a Core Technical
Committee (CTC) which is responsible for high-level guidance of the project.
## Collaborators
The [nodejs/node](https://github.com/nodejs/node) GitHub repository is
maintained by the CTC and additional Collaborators who are added by the
CTC on an ongoing basis.
maintained by Collaborators who are added by the CTC on an ongoing basis.
Individuals identified by the CTC as making significant and valuable
contributions are made Collaborators and given commit access to the project.
_Note:_ If you make a significant contribution and are not considered
for commit access, log an issue or contact a CTC member directly.
contributions are made Collaborators and given commit access to the project. If
you make a significant contribution and are not considered for commit access,
log an issue or contact a CTC member directly.
Modifications of the contents of the nodejs/node repository are made on
a collaborative basis. Anybody with a GitHub account may propose a
......@@ -45,18 +29,15 @@ be accepted unless:
the change. Previously-objecting Collaborators do not necessarily have to
sign-off on the change, but they should not be opposed to it.
* The change is escalated to the CTC and the CTC votes to approve the change.
This should be used only after other options (especially discussion among
the disagreeing Collaborators) have been exhausted.
This should only happen if disagreements between Collaborators cannot be
resolved through discussion.
Collaborators may opt to elevate significant or controversial modifications to
the CTC by assigning the `ctc-review` label to a pull request or issue. The
CTC should serve as the final arbiter where required.
For the current list of Collaborators, see the project
[README.md](./README.md#current-project-team-members).
A guide for Collaborators is maintained in
[COLLABORATOR_GUIDE.md](./COLLABORATOR_GUIDE.md).
* [Current list of Collaborators](./README.md#current-project-team-members)
* [A guide for Collaborators](./COLLABORATOR_GUIDE.md)
### Collaborator Activities
......@@ -68,9 +49,23 @@ Typical activities of a Collaborator include:
* participation in working groups
* merging pull requests
While the above are typical things done by Collaborators, there are no required
activities to retain Collaborator status. There is currently no process by which
inactive Collaborators are removed from the project.
The CTC periodically reviews the Collaborator list to identify inactive
Collaborators. Past Collaborators are typically given _Emeritus_ status. Emeriti
may request that the CTC restore them to active status.
## Core Technical Committee
The Core Technical Committee (CTC) has final authority over this project
including:
* Technical direction
* Project governance and process (including this policy)
* Contribution policy
* GitHub repository hosting
* Conduct guidelines
* Maintaining the list of additional Collaborators
* [Current list of CTC members](./README.md#current-project-team-members)
## CTC Membership
......@@ -83,9 +78,10 @@ membership beyond these rules.
The CTC may add additional members to the CTC by a standard CTC motion.
When a CTC member's participation in [CTC activities](#ctc-activities) has become
minimal for a sustained period of time, the CTC will request that the member
either indicate an intention to increase participation or voluntarily resign.
When a CTC member's participation in [CTC activities](#ctc-activities) has
become minimal for a sustained period of time, the CTC will request that the
member either indicate an intention to increase participation or voluntarily
resign.
CTC members may only be removed by voluntary resignation or through a standard
CTC motion.
......
......@@ -122,7 +122,7 @@ test: all
$(MAKE) build-addons
$(MAKE) cctest
$(PYTHON) tools/test.py --mode=release -J \
addons doctool inspector known_issues message pseudo-tty parallel sequential
doctool inspector known_issues message pseudo-tty parallel sequential addons
$(MAKE) lint
test-parallel: all
......@@ -186,6 +186,14 @@ test/addons/.buildstamp: config.gypi \
# TODO(bnoordhuis) Force rebuild after gyp update.
build-addons: $(NODE_EXE) test/addons/.buildstamp
clear-stalled:
# Clean up any leftover processes but don't error if found.
ps awwx | grep Release/node | grep -v grep | cat
@PS_OUT=`ps awwx | grep Release/node | grep -v grep | awk '{print $$1}'`; \
if [ "$${PS_OUT}" ]; then \
echo $${PS_OUT} | xargs kill; \
fi
test-gc: all test/gc/node_modules/weak/build/Release/weakref.node
$(PYTHON) tools/test.py --mode=release gc
......@@ -208,26 +216,28 @@ test-ci-native: | test/addons/.buildstamp
$(TEST_CI_ARGS) $(CI_NATIVE_SUITES)
# This target should not use a native compiler at all
test-ci-js:
test-ci-js: | clear-stalled
$(PYTHON) tools/test.py $(PARALLEL_ARGS) -p tap --logfile test.tap \
--mode=release --flaky-tests=$(FLAKY_TESTS) \
$(TEST_CI_ARGS) $(CI_JS_SUITES)
# Clean up any leftover processes
PS_OUT=`ps awwx | grep Release/node | grep -v grep | awk '{print $$1}'`; \
# Clean up any leftover processes, error if found.
ps awwx | grep Release/node | grep -v grep | cat
@PS_OUT=`ps awwx | grep Release/node | grep -v grep | awk '{print $$1}'`; \
if [ "$${PS_OUT}" ]; then \
echo $${PS_OUT} | $(XARGS) kill; exit 1; \
fi
test-ci: LOGLEVEL := info
test-ci: | build-addons
test-ci: | clear-stalled build-addons
out/Release/cctest --gtest_output=tap:cctest.tap
$(PYTHON) tools/test.py $(PARALLEL_ARGS) -p tap --logfile test.tap \
--mode=release --flaky-tests=$(FLAKY_TESTS) \
$(TEST_CI_ARGS) $(CI_NATIVE_SUITES) $(CI_JS_SUITES)
# Clean up any leftover processes
PS_OUT=`ps awwx | grep Release/node | grep -v grep | awk '{print $$1}'`; \
$(TEST_CI_ARGS) $(CI_JS_SUITES) $(CI_NATIVE_SUITES)
# Clean up any leftover processes, error if found.
ps awwx | grep Release/node | grep -v grep | cat
@PS_OUT=`ps awwx | grep Release/node | grep -v grep | awk '{print $$1}'`; \
if [ "$${PS_OUT}" ]; then \
echo $${PS_OUT} | $(XARGS) kill; exit 1; \
echo $${PS_OUT} | xargs kill; exit 1; \
fi
test-release: test-build
......@@ -286,13 +296,15 @@ test-timers-clean:
ifneq ("","$(wildcard deps/v8/tools/run-tests.py)")
test-v8: v8 test-hash-seed
test-v8: v8
# note: performs full test unless QUICKCHECK is specified
deps/v8/tools/run-tests.py --arch=$(V8_ARCH) \
--mode=$(BUILDTYPE_LOWER) $(V8_TEST_OPTIONS) $(QUICKCHECK_ARG) \
--no-presubmit \
--shell-dir=$(PWD)/deps/v8/out/$(V8_ARCH).$(BUILDTYPE_LOWER) \
$(TAP_V8)
@echo Testing hash seed
$(MAKE) test-hash-seed
test-v8-intl: v8
# note: performs full test unless QUICKCHECK is specified
......@@ -512,7 +524,7 @@ endif
BINARYTAR=$(BINARYNAME).tar
# OSX doesn't have xz installed by default, http://macpkg.sourceforge.net/
XZ=$(shell which xz > /dev/null 2>&1; echo $$?)
XZ_COMPRESSION ?= 9
XZ_COMPRESSION ?= 9e
PKG=$(TARNAME).pkg
PACKAGEMAKER ?= /Developer/Applications/Utilities/PackageMaker.app/Contents/MacOS/PackageMaker
PKGDIR=out/dist-osx
......@@ -568,9 +580,9 @@ pkg: $(PKG)
pkg-upload: pkg
ssh $(STAGINGSERVER) "mkdir -p nodejs/$(DISTTYPEDIR)/$(FULLVERSION)"
chmod 664 node-$(FULLVERSION).pkg
scp -p node-$(FULLVERSION).pkg $(STAGINGSERVER):nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/node-$(FULLVERSION).pkg
ssh $(STAGINGSERVER) "touch nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/node-$(FULLVERSION).pkg.done"
chmod 664 $(TARNAME).pkg
scp -p $(TARNAME).pkg $(STAGINGSERVER):nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/$(TARNAME).pkg
ssh $(STAGINGSERVER) "touch nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/$(TARNAME).pkg.done"
$(TARBALL): release-only $(NODE_EXE) doc
git checkout-index -a -f --prefix=$(TARNAME)/
......@@ -600,19 +612,19 @@ tar: $(TARBALL)
tar-upload: tar
ssh $(STAGINGSERVER) "mkdir -p nodejs/$(DISTTYPEDIR)/$(FULLVERSION)"
chmod 664 node-$(FULLVERSION).tar.gz
scp -p node-$(FULLVERSION).tar.gz $(STAGINGSERVER):nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/node-$(FULLVERSION).tar.gz
ssh $(STAGINGSERVER) "touch nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/node-$(FULLVERSION).tar.gz.done"
chmod 664 $(TARNAME).tar.gz
scp -p $(TARNAME).tar.gz $(STAGINGSERVER):nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/$(TARNAME).tar.gz
ssh $(STAGINGSERVER) "touch nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/$(TARNAME).tar.gz.done"
ifeq ($(XZ), 0)
chmod 664 node-$(FULLVERSION).tar.xz
scp -p node-$(FULLVERSION).tar.xz $(STAGINGSERVER):nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/node-$(FULLVERSION).tar.xz
ssh $(STAGINGSERVER) "touch nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/node-$(FULLVERSION).tar.xz.done"
chmod 664 $(TARNAME).tar.xz
scp -p $(TARNAME).tar.xz $(STAGINGSERVER):nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/$(TARNAME).tar.xz
ssh $(STAGINGSERVER) "touch nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/$(TARNAME).tar.xz.done"
endif
doc-upload: doc
ssh $(STAGINGSERVER) "mkdir -p nodejs/$(DISTTYPEDIR)/$(FULLVERSION)"
ssh $(STAGINGSERVER) "mkdir -p nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/docs/"
chmod -R ug=rw-x+X,o=r+X out/doc/
scp -pr out/doc/ $(STAGINGSERVER):nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/docs/
scp -pr out/doc/* $(STAGINGSERVER):nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/docs/
ssh $(STAGINGSERVER) "touch nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/docs.done"
$(TARBALL)-headers: release-only
......@@ -670,13 +682,13 @@ binary: $(BINARYTAR)
binary-upload: binary
ssh $(STAGINGSERVER) "mkdir -p nodejs/$(DISTTYPEDIR)/$(FULLVERSION)"
chmod 664 node-$(FULLVERSION)-$(OSTYPE)-$(ARCH).tar.gz
scp -p node-$(FULLVERSION)-$(OSTYPE)-$(ARCH).tar.gz $(STAGINGSERVER):nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/node-$(FULLVERSION)-$(OSTYPE)-$(ARCH).tar.gz
ssh $(STAGINGSERVER) "touch nodejs/$(DISTTYPEDIR)/$(FULLVERSION)/node-$(FULLVERSION)-$(OSTYPE)-$(ARCH).tar.gz.done"
chmod 664 $(TARNAME)-$(OSTYPE)-$(ARCH).tar.gz