Release proposal: v11.1.0

.travis.yml

@@ -1,6 +1,4 @@
 language: cpp
-compiler:
-  - clang
 sudo: false
 cache: ccache
 os: linux
@@ -15,12 +13,15 @@ matrix:
         # Lint the first commit in the PR.
         - \[ -z "$TRAVIS_COMMIT_RANGE" \] || (echo -e '\nLinting the commit message according to the guidelines at https://goo.gl/p2fr5Q\n' && git log $TRAVIS_COMMIT_RANGE --pretty=format:'%h' --no-merges | tail -1 | xargs npx -q core-validate-commit --no-validate-metadata)
     - name: "Test Suite"
+      addons:
+        apt:
+          sources:
+            - ubuntu-toolchain-r-test
+          packages:
+            - g++-4.9
       install:
+        - export CC='ccache gcc-4.9' CXX='ccache g++-4.9' JOBS=2
         - ./configure
         - make -j2 V=
       script:
-        - make -j2 test
-      before_install:
-        - export CXX="ccache clang++ -Qunused-arguments"
-        - export CC="ccache clang -Qunused-arguments -Wno-unknown-warning-option"
-        - export JOBS=2
+        - PARALLEL_ARGS='--flaky-tests=skip' make -j1 test

BUILDING.md

@@ -24,6 +24,7 @@ file a new issue.
     * [Prerequisites](#prerequisites)
     * [Building Node.js](#building-nodejs-1)
     * [Running Tests](#running-tests)
+    * [Running Coverage](#running-coverage)
     * [Building the documentation](#building-the-documentation)
     * [Building a debug build](#building-a-debug-build)
   * [Windows](#windows-1)
@@ -48,29 +49,28 @@ file a new issue.
 ## Supported platforms
 
 This list of supported platforms is current as of the branch/release to
-which it is attached.
+which it belongs.
 
 ### Input
 
 Node.js relies on V8 and libuv. We adopt a subset of their supported platforms.
 
 ### Strategy
 
-Support is divided into three tiers:
+There are three support tiers:
 
 * **Tier 1**: Full test coverage and maintenance by the Node.js core team and
   the broader community.
-* **Tier 2**: Full test coverage but more limited maintenance,
-  often provided by the vendor of the platform.
-* **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.
+* **Tier 2**: Full test coverage. Limited maintenance, often provided by the
+  vendor of the platform.
+* **Experimental**: May not compile or test suite may not pass.
+  These are often approaching Tier 2 support but are not quite ready.
+  There is at least one individual providing maintenance.
 
 ### 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
+Thus, we do not recommend that you use Node.js on end-of-life or unsupported
 platforms in production.
 
 | System       | Support type | Version                         | Architectures    | Notes                         |
@@ -223,6 +223,13 @@ $ make -j4 test
 `make -j4 test` does a full check on the codebase, including running linters and
 documentation tests.
 
+Make sure the linter does not report any issues and that all tests pass. Please
+do not submit patches that fail either check.
+
+If you want to run the linter without running tests, use
+`make lint`/`vcbuild lint`. It will run both JavaScript linting and
+C++ linting.
+
 If you are updating tests and just want to run a single test to check it:
 
 ```text
@@ -249,18 +256,35 @@ You can usually run tests directly with node:
 $ ./node ./test/parallel/test-stream2-transform.js
 ```
 
-Optionally, continue below.
+Remember to recompile with `make -j4` in between test runs if you change code in
+the `lib` or `src` directories.
+
+#### Running Coverage
 
-To run the tests and generate code coverage reports:
+It's good practice to ensure any code you add or change is covered by tests.
+You can do so by running the test suite with coverage enabled:
 
 ```console
 $ ./configure --coverage
 $ make coverage
 ```
 
-This will generate coverage reports for both JavaScript and C++ tests (if you
-only want to run the JavaScript tests then you do not need to run the first
-command `./configure --coverage`).
+A detailed coverage report will be written to `coverage/index.html` for
+JavaScript coverage and to `coverage/cxxcoverage.html` for C++ coverage
+(if you only want to run the JavaScript tests then you do not need to run
+the first command `./configure --coverage`).
+
+_Generating a test coverage report can take several minutes._
+
+To collect coverage for a subset of tests you can set the `CI_JS_SUITES` and
+`CI_NATIVE_SUITES` variables:
+
+```text
+$ CI_JS_SUITES=child-process CI_NATIVE_SUITES= make coverage
+```
+
+The above command executes tests for the `child-process` subsystem and
+outputs the resulting coverage report.
 
 The `make coverage` command downloads some tools to the project root directory
 and overwrites the `lib/` directory. To clean up after generating the coverage
@@ -470,6 +494,10 @@ You can find other ICU releases at
 Download the file named something like `icu4c-**##.#**-src.tgz` (or
 `.zip`).
 
+To check the minimum recommended ICU, run `./configure --help` and see
+the help for the `--with-icu-source` option. A warning will be printed
+during configuration if the ICU version is too old.
+
 ##### Unix/macOS
 
 From an already-unpacked ICU:
@@ -524,3 +552,14 @@ To make `./myModule.js` available via `require('myModule')` and
 ```console
 > .\vcbuild link-module './myModule.js' link-module './myModule2.js'
 ```
+
+## Note for downstream distributors of Node.js
+
+The Node.js ecosystem is reliant on ABI compatibility within a major
+release. To maintain ABI compatibility it is required that production
+builds of Node.js will be built against the same version of dependencies as the
+project vendors. If Node.js is to be built against a different version of a
+dependency please create a custom `NODE_MODULE_VERSION` to ensure ecosystem
+compatibility. Please consult with the TSC by opening an issue at
+https://github.com/nodejs/tsc/issues if you decide to create a custom
+`NODE_MODULE_VERSION` so we can avoid duplication in the ecosystem.

CHANGELOG.md

@@ -33,7 +33,8 @@ release.
 </tr>
 <tr>
     <td valign="top">
-<b><a href="doc/changelogs/CHANGELOG_V11.md#11.0.0">11.0.0</a></b><br/>
+<b><a href="doc/changelogs/CHANGELOG_V11.md#11.1.0">11.1.0</a></b><br/>
+<a href="doc/changelogs/CHANGELOG_V11.md#11.0.0">11.0.0</a><br/>
     </td>
     <td valign="top">
 <b><a href="doc/changelogs/CHANGELOG_V10.md#10.12.0">10.12.0</a></b><br/>

CPP_STYLE_GUIDE.md

@@ -18,6 +18,7 @@
 * [Memory Management](#memory-management)
   * [Memory allocation](#memory-allocation)
   * [Use `nullptr` instead of `NULL` or `0`](#use-nullptr-instead-of-null-or-0)
+  * [Use explicit pointer comparisons](#use-explicit-pointer-comparisons)
   * [Ownership and Smart Pointers](#ownership-and-smart-pointers)
   * [Avoid non-const references](#avoid-non-const-references)
 * [Others](#others)
@@ -195,6 +196,12 @@ class FancyContainer {
 
 Further reading in the [C++ Core Guidelines][ES.47].
 
+### Use explicit pointer comparisons
+
+Use explicit comparisons to `nullptr` when testing pointers, i.e.
+`if (foo == nullptr)` instead of `if (foo)` and
+`foo != nullptr` instead of `!foo`.
+
 ### Ownership and Smart Pointers
 
 * [R.20]: Use `std::unique_ptr` or `std::shared_ptr` to represent ownership

Makefile

@@ -270,7 +270,7 @@ v8:
 	tools/make-v8.sh $(V8_ARCH).$(BUILDTYPE_LOWER) $(V8_BUILD_OPTIONS)
 
 .PHONY: jstest
-jstest: build-addons build-addons-napi ## Runs addon tests and JS tests
+jstest: build-addons build-addons-napi bench-addons-build ## Runs addon tests and JS tests
 	$(PYTHON) tools/test.py $(PARALLEL_ARGS) --mode=$(BUILDTYPE_LOWER) \
 		--skip-tests=$(CI_SKIP_TESTS) \
 		$(CI_JS_SUITES) \
@@ -414,7 +414,7 @@ clear-stalled:
 		echo $${PS_OUT} | xargs kill -9; \
 	fi
 
-test-build: | all build-addons build-addons-napi
+test-build: | all build-addons build-addons-napi bench-addons-build
 
 test-build-addons-napi: all build-addons-napi
 
@@ -444,7 +444,7 @@ test-ci-native: | test/addons/.buildstamp test/addons-napi/.buildstamp
 test-ci-js: | clear-stalled
 	$(PYTHON) tools/test.py $(PARALLEL_ARGS) -p tap --logfile test.tap \
 		--mode=$(BUILDTYPE_LOWER) --flaky-tests=$(FLAKY_TESTS) \
-		$(TEST_CI_ARGS) $(CI_JS_SUITES)
+		$(TEST_CI_ARGS) $(CI_JS_SUITES) --skip-tests=sequential/test-benchmark-napi
 	@echo "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}'`; \
@@ -455,7 +455,7 @@ test-ci-js: | clear-stalled
 .PHONY: test-ci
 # Related CI jobs: most CI tests, excluding node-test-commit-arm-fanned
 test-ci: LOGLEVEL := info
-test-ci: | clear-stalled build-addons build-addons-napi doc-only
+test-ci: | clear-stalled build-addons build-addons-napi doc-only bench-addons-build
 	out/Release/cctest --gtest_output=tap:cctest.tap
 	$(PYTHON) tools/test.py $(PARALLEL_ARGS) -p tap --logfile test.tap \
 		--mode=$(BUILDTYPE_LOWER) --flaky-tests=$(FLAKY_TESTS) \
@@ -496,7 +496,7 @@ test-debug: test-build
 test-message: test-build
 	$(PYTHON) tools/test.py $(PARALLEL_ARGS) message
 
-test-simple: | cctest  # Depends on 'all'.
+test-simple: | cctest bench-addons-build  # Depends on 'all'.
 	$(PYTHON) tools/test.py $(PARALLEL_ARGS) parallel sequential
 
 test-pummel: all
@@ -1208,6 +1208,28 @@ lint-addon-docs: test/addons/.docbuildstamp
 cpplint: lint-cpp
 	@echo "Please use lint-cpp instead of cpplint"
 
+.PHONY: lint-py-build
+# python -m pip install flake8
+# Try with '--system' is to overcome systems that blindly set '--user'
+lint-py-build:
+	@echo "Pip installing flake8 linter on $(shell $(PYTHON) --version)..."
+	$(PYTHON) -m pip install --upgrade -t tools/pip/site-packages flake8 || \
+		$(PYTHON) -m pip install --upgrade --system -t tools/pip/site-packages flake8
+
+ifneq ("","$(wildcard tools/pip/site-packages)")
+.PHONY: lint-py
+# Lints the Python code with flake8.
+# Flag the build if there are Python syntax errors or undefined names
+lint-py:
+	PYTHONPATH=tools/pip $(PYTHON) -m flake8 . \
+		--count --show-source --statistics --select=E901,E999,F821,F822,F823 \
+		--exclude=deps,lib,src,tools/*_macros.py,tools/gyp,tools/jinja2,tools/pip
+else
+lint-py:
+	@echo "Python linting with flake8 is not avalible"
+	@echo "Run 'make lint-py-build'"
+endif
+
 .PHONY: lint
 .PHONY: lint-ci
 ifneq ("","$(wildcard tools/node_modules/eslint/)")
@@ -1221,7 +1243,7 @@ lint: ## Run JS, C++, MD and doc linters.
 CONFLICT_RE=^>>>>>>> [0-9A-Fa-f]+|^<<<<<<< [A-Za-z]+
 
 # Related CI job: node-test-linter
-lint-ci: lint-js-ci lint-cpp lint-md lint-addon-docs
+lint-ci: lint-js-ci lint-cpp lint-py lint-md lint-addon-docs
 	@if ! ( grep -IEqrs "$(CONFLICT_RE)" benchmark deps doc lib src test tools ) \
 		&& ! ( find . -maxdepth 1 -type f | xargs grep -IEqs "$(CONFLICT_RE)" ); then \
 		exit 0 ; \

README.md

@@ -31,7 +31,7 @@ The Node.js project uses an [open governance model](./GOVERNANCE.md). The
 * [Current Project Team Members](#current-project-team-members)
   * [TSC (Technical Steering Committee)](#tsc-technical-steering-committee)
   * [Collaborators](#collaborators)
-  * [Release Team](#release-team)
+  * [Release Keys](#release-keys)
 * [Contributing to Node.js](#contributing-to-nodejs)
 
 ## Support
@@ -81,7 +81,7 @@ your expectations.
   changes. Use with caution.
 
 Current and LTS releases follow [Semantic Versioning](https://semver.org). A
-member of the [Release Team](#release-team) signs each Current and LTS release.
+member of the Release Team [signs](#release-keys) each Current and LTS release.
 For more information, see the
 [Release README](https://github.com/nodejs/Release).
 
@@ -133,9 +133,9 @@ $ grep node-vx.y.z.tar.gz SHASUMS256.txt | sha256sum -c -
 
 For Current and LTS, the GPG detached signature of `SHASUMS256.txt` is in
 `SHASUMS256.txt.sig`. You can use it with `gpg` to verify the integrity of
-`SHASUM256.txt`. You will first need to import all the GPG keys of individuals
-authorized to create releases. They are at the bottom of this README under
-[Release Team](#release-team). To import the keys:
+`SHASUM256.txt`. You will first need to import
+[the GPG keys of individuals authorized to create releases](#release-keys). To
+import the keys:
 
 ```console
 $ gpg --keyserver pool.sks-keyservers.net --recv-keys DD8F2338BAE7501E3DD5AC78C273792F7D83545D
@@ -179,27 +179,20 @@ nonetheless.
   arbitrary JavaScript code. That is already the highest level of privilege
   possible.
 
-- [#12141](https://github.com/nodejs/node/pull/12141): _buffer: zero fill
-  Buffer(num) by default_. The documented `Buffer()` behavior was prone to
-  [misuse](https://snyk.io/blog/exploiting-buffer/). It has since changed. It
-  was not deemed serious enough to fix in older releases and breaking API
-  stability.
-
 ### Private disclosure preferred
 
 - [CVE-2016-7099](https://nodejs.org/en/blog/vulnerability/september-2016-security-releases/):
-  _Fix invalid wildcard certificate validation check_. This is a high severity
-  defect that would allow a malicious TLS server to serve an invalid wildcard
-  certificate for its hostname and be improperly validated by a Node.js client.
+  _Fix invalid wildcard certificate validation check_. This was a high-severity
+  defect. It caused Node.js TLS clients to accept invalid wildcard certificates.
 
 - [#5507](https://github.com/nodejs/node/pull/5507): _Fix a defect that makes
   the CacheBleed Attack possible_. Many, though not all, OpenSSL vulnerabilities
   in the TLS/SSL protocols also affect Node.js.
 
 - [CVE-2016-2216](https://nodejs.org/en/blog/vulnerability/february-2016-security-releases/):
   _Fix defects in HTTP header parsing for requests and responses that can allow
-  response splitting_. While the impact of this vulnerability is application and
-  network dependent, it is remotely exploitable in the HTTP protocol.
+  response splitting_. This was a remotely-exploitable defect in the Node.js
+  HTTP implementation.
 
 When in doubt, please do send us a report.
 
@@ -443,8 +436,6 @@ For information about the governance of the Node.js project, see
 **Alexis Campailla** <orangemocha@nodejs.org>
 * [othiym23](https://github.com/othiym23) -
 **Forrest L Norvell** <ogd@aoaioxxysz.net> (he/him)
-* [phillipj](https://github.com/phillipj) -
-**Phillip Johnsen** <johphi@gmail.com>
 * [pmq20](https://github.com/pmq20) -
 **Minqi Pan** <pmq2001@gmail.com>
 * [princejwesley](https://github.com/princejwesley) -
@@ -544,6 +535,8 @@ For information about the governance of the Node.js project, see
 **Oleg Elifantiev** <oleg@elifantiev.ru>
 * [petkaantonov](https://github.com/petkaantonov) -
 **Petka Antonov** <petka_antonov@hotmail.com>
+* [phillipj](https://github.com/phillipj) -
+**Phillip Johnsen** <johphi@gmail.com>
 * [piscisaureus](https://github.com/piscisaureus) -
 **Bert Belder** <bertbelder@gmail.com>
 * [rlidwka](https://github.com/rlidwka) -
@@ -562,9 +555,9 @@ For information about the governance of the Node.js project, see
 Collaborators follow the [COLLABORATOR_GUIDE.md](./COLLABORATOR_GUIDE.md) in
 maintaining the Node.js project.
 
-### Release Team
+### Release Keys
 
-Node.js releases are signed with one of the following GPG keys:
+GPG keys used to sign Node.js releases:
 
 * **Colin Ihrig** <cjihrig@gmail.com>
 `94AE36675C464D64BAFA68DD7434390BDBE9B9C5`