From 5ffdb738eb96991a6735b7484e94be8dabe68bcb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Tue, 24 Sep 2019 00:15:57 +0300 Subject: [PATCH 01/14] add a draft for node version/testing blog post --- .../blog-201909-please-test-against-lts.md | 47 +++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 docs/drafts/blog-201909-please-test-against-lts.md diff --git a/docs/drafts/blog-201909-please-test-against-lts.md b/docs/drafts/blog-201909-please-test-against-lts.md new file mode 100644 index 00000000..bae9027b --- /dev/null +++ b/docs/drafts/blog-201909-please-test-against-lts.md @@ -0,0 +1,47 @@ +# Which versions of node should library authors test against? + +tl;dr: we'd like to encourage package authors to make sure their Continuous Integration (CI) setup includes all supported Node.js "long-term support" (LTS) versions, as well as the Current stable release. + +At the start of 2019, npm released a [list of top 1000 most downloaded packages](https://docs.google.com/spreadsheets/d/1lZDNYsLntwD2q9XaTw-XLuG0VpHH6cOV-Uoa7Y1aTSM/edit#gid=1745448509). We scanned that list to find that a large number of these packages have not been updated in over a year, but even if they have - they still did not include the latest Node.js LTS version (10.x at the time) in their Continuous Integration (CI) setup. + +It is important to note, that CI providers, including Travis (the de facto standard1 in JavaScript package ecosystem) **might not be using LTS** as the default. This [will change soon](https://github.com/travis-ci/travis-build/pull/1747), however it is a good time to double check your testing configuration - in October, 2019 Node.js 12.x will become the active LTS version and 13.x will be released and at the end of December, 2019 Node.js 8.x will reach end-of-life. + +## Why + +The [release schedule](https://nodejs.org/en/about/releases/) of Node.js is set up to have a new release with breaking changes every 6 months. According to [semver](https://semver.org), each such release increments the major version number. Even-numbered releases (10, 12, etc) receive "long-term support" (30 months) and because of that only LTS versions are recommended to be used in production applications. + +While library authors are free to chose any support policy2 they prefer, their libraries are likely to be used in up to 3 LTS versions that might be supported at any given time. We recommend to include all of these versions in the CI test matrix. At the time of writing this would mean Node.js 8 and 10. By January, 2020 this will become 10 and 12. + +Odd-numbered (11, 13, etc) Node.js releases typically become unsupported after 6 months when a new even-numbered release is made available. While it is generally recommended that production applications do not use non-LTS Node.js versions, for library authors the recommendation is different - we'd like to encourage you to include the Current version (at the time of writing - 12, in January, 2020 - 13) in the test matrix, as this can serve as an advance warning for both - library authors and Node.js maintainers3. + +The above recommendation is for the minimal set of versions that should be supported - if it is an option at all, we'd like to encourage everyone to support older versions as well. + +## How: setting up your `.travis.yml` + +Travis uses [`nvm`](https://github.com/nvm-sh/nvm) to install node, so you can use any version or keyword it supports in your [`.travis.yml`](https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#specifying-nodejs-versions). This means that your setup should look something like this: + +``` +language: node_js +node_js: + - node # Current stable, i.e. 12 in September, 2019 + - lts/* # Most recent LTS version, i.e. 10 in September, 2019 + - 8 # Explictly include the maintenance LTS version +``` + +When you use the keywords (`node`, `lts/*`), you will automatically start testing in new versions as they come out. This does, however, mean that you will also automatically _stop_ testing in versions that may still need to be supported. + +## How: setting up automated updates + +(todo) + +## How: dropping support for older Node.js versions + +Maintaining an Open Source Software library can become a burden and it is unfeasible to expect that all versions of Node.js should be supported by library authors indefinitely. Changing the minimum Node.js version requirement is considered a breaking change and according to semver rules requires a major version of your package to be incremented. + +You should also keep the [`engines` field](https://docs.npmjs.com/files/package.json#engines) in your `package.json` up to date to indicate supported versions. + +## Footnotes + +1. Out of top 1000 packages, 877 were pointing to GitHub repos with a `.travis.yml` file at the root in September 2019. +2. The [Package Maintenance Working Group](https://github.com/nodejs/package-maintenance/) is working on a way to [define your support levels](https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/PACKAGE-SUPPORT.md) - we welcome discussions and contributions. +3. The Node.js project also runs some smoke tests using The [Canary in the Goldmine tool](https://github.com/nodejs/citgm). From dd0f009eac05ad63814cdc73c02b0dee094872bb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Wed, 2 Oct 2019 23:26:06 +0300 Subject: [PATCH 02/14] add footnote with lts numbers; update to october; mention aws node 8 --- .../blog-201909-please-test-against-lts.md | 21 +++++++++++-------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/docs/drafts/blog-201909-please-test-against-lts.md b/docs/drafts/blog-201909-please-test-against-lts.md index bae9027b..4a7685a8 100644 --- a/docs/drafts/blog-201909-please-test-against-lts.md +++ b/docs/drafts/blog-201909-please-test-against-lts.md @@ -2,20 +2,22 @@ tl;dr: we'd like to encourage package authors to make sure their Continuous Integration (CI) setup includes all supported Node.js "long-term support" (LTS) versions, as well as the Current stable release. -At the start of 2019, npm released a [list of top 1000 most downloaded packages](https://docs.google.com/spreadsheets/d/1lZDNYsLntwD2q9XaTw-XLuG0VpHH6cOV-Uoa7Y1aTSM/edit#gid=1745448509). We scanned that list to find that a large number of these packages have not been updated in over a year, but even if they have - they still did not include the latest Node.js LTS version (10.x at the time) in their Continuous Integration (CI) setup. +At the start of 2019, npm released a [list of top 1000 most downloaded packages](https://docs.google.com/spreadsheets/d/1lZDNYsLntwD2q9XaTw-XLuG0VpHH6cOV-Uoa7Y1aTSM/edit#gid=1745448509). We scanned that list to find that a large number of these packages have not been updated in over a year, but even if they have - they still did not include the latest Node.js LTS version (10.x at the time) in their Continuous Integration (CI) setup.1 -It is important to note, that CI providers, including Travis (the de facto standard1 in JavaScript package ecosystem) **might not be using LTS** as the default. This [will change soon](https://github.com/travis-ci/travis-build/pull/1747), however it is a good time to double check your testing configuration - in October, 2019 Node.js 12.x will become the active LTS version and 13.x will be released and at the end of December, 2019 Node.js 8.x will reach end-of-life. +It is important to note, that CI providers, including Travis (the de facto standard2 in JavaScript package ecosystem) **might not be using LTS** as the default. This [will change soon](https://github.com/travis-ci/travis-build/pull/1747), however it is a good time to double check your testing configuration - in October, 2019 Node.js 12.x will become the active LTS version and 13.x will be released and at the end of December, 2019 Node.js 8.x will reach end-of-life. ## Why The [release schedule](https://nodejs.org/en/about/releases/) of Node.js is set up to have a new release with breaking changes every 6 months. According to [semver](https://semver.org), each such release increments the major version number. Even-numbered releases (10, 12, etc) receive "long-term support" (30 months) and because of that only LTS versions are recommended to be used in production applications. -While library authors are free to chose any support policy2 they prefer, their libraries are likely to be used in up to 3 LTS versions that might be supported at any given time. We recommend to include all of these versions in the CI test matrix. At the time of writing this would mean Node.js 8 and 10. By January, 2020 this will become 10 and 12. +While library authors are free to chose any support policy3 they prefer, their libraries are likely to be used in up to 3 LTS versions that might be supported at any given time. We recommend to include all of these versions in the CI test matrix. At the time of writing this would mean Node.js 8 and 10. By January, 2020 this will become 10 and 12. -Odd-numbered (11, 13, etc) Node.js releases typically become unsupported after 6 months when a new even-numbered release is made available. While it is generally recommended that production applications do not use non-LTS Node.js versions, for library authors the recommendation is different - we'd like to encourage you to include the Current version (at the time of writing - 12, in January, 2020 - 13) in the test matrix, as this can serve as an advance warning for both - library authors and Node.js maintainers3. +Odd-numbered (11, 13, etc) Node.js releases typically become unsupported after 6 months when a new even-numbered release is made available. While it is generally recommended that production applications do not use non-LTS Node.js versions, for library authors the recommendation is different - we'd like to encourage you to include the Current version (at the time of writing - 12, in January, 2020 - 13) in the test matrix, as this can serve as an advance warning for both - library authors and Node.js maintainers4. The above recommendation is for the minimal set of versions that should be supported - if it is an option at all, we'd like to encourage everyone to support older versions as well. +Additionally, while it is recommended to use (and therefore test in) the latest version of each major release line, you may want to additionally support some specific versions, e.g. 8.10.0 is used by AWS Lambda, even though 8.16.1 is available - if that is your support target, you might not have all the features added since then. + ## How: setting up your `.travis.yml` Travis uses [`nvm`](https://github.com/nvm-sh/nvm) to install node, so you can use any version or keyword it supports in your [`.travis.yml`](https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#specifying-nodejs-versions). This means that your setup should look something like this: @@ -23,8 +25,8 @@ Travis uses [`nvm`](https://github.com/nvm-sh/nvm) to install node, so you can u ``` language: node_js node_js: - - node # Current stable, i.e. 12 in September, 2019 - - lts/* # Most recent LTS version, i.e. 10 in September, 2019 + - node # Current stable, i.e. 12 in October, 2019 + - lts/* # Most recent LTS version, i.e. 10 in October, 2019 - 8 # Explictly include the maintenance LTS version ``` @@ -42,6 +44,7 @@ You should also keep the [`engines` field](https://docs.npmjs.com/files/package. ## Footnotes -1. Out of top 1000 packages, 877 were pointing to GitHub repos with a `.travis.yml` file at the root in September 2019. -2. The [Package Maintenance Working Group](https://github.com/nodejs/package-maintenance/) is working on a way to [define your support levels](https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/PACKAGE-SUPPORT.md) - we welcome discussions and contributions. -3. The Node.js project also runs some smoke tests using The [Canary in the Goldmine tool](https://github.com/nodejs/citgm). +1. Out of top 1000 packages using Travis for CI, 315 had neither a variation of 10.x nor `lts/*` in their setup; ~150 of those had commits since 10.x was first released, of which ~120 had commits since 10.x became active LTS. +2. Out of top 1000 packages, 877 were pointing to GitHub repos with a `.travis.yml` file at the root in September 2019. +3. The [Package Maintenance Working Group](https://github.com/nodejs/package-maintenance/) is working on a way to [define your support levels](https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/PACKAGE-SUPPORT.md) - we welcome discussions and contributions. +4. The Node.js project also runs some smoke tests using The [Canary in the Goldmine tool](https://github.com/nodejs/citgm). From 03599107478ba94b6653ed1c7cc990500954c744 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Wed, 2 Oct 2019 23:49:49 +0300 Subject: [PATCH 03/14] add a note about Renovate --- ...-against-lts.md => blog-201910-please-test-against-lts.md} | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) rename docs/drafts/{blog-201909-please-test-against-lts.md => blog-201910-please-test-against-lts.md} (97%) diff --git a/docs/drafts/blog-201909-please-test-against-lts.md b/docs/drafts/blog-201910-please-test-against-lts.md similarity index 97% rename from docs/drafts/blog-201909-please-test-against-lts.md rename to docs/drafts/blog-201910-please-test-against-lts.md index 4a7685a8..18d64631 100644 --- a/docs/drafts/blog-201909-please-test-against-lts.md +++ b/docs/drafts/blog-201910-please-test-against-lts.md @@ -32,9 +32,7 @@ node_js: When you use the keywords (`node`, `lts/*`), you will automatically start testing in new versions as they come out. This does, however, mean that you will also automatically _stop_ testing in versions that may still need to be supported. -## How: setting up automated updates - -(todo) +Alternatively, you can use [Renovate](https://docs.renovatebot.com/node/) to automatically add new versions to your `.travis.yml`. ## How: dropping support for older Node.js versions From 10671b070c85b560bc42659b30137f8ddb2afbdf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Thu, 3 Oct 2019 00:28:49 +0300 Subject: [PATCH 04/14] tweak wording --- docs/drafts/blog-201910-please-test-against-lts.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/docs/drafts/blog-201910-please-test-against-lts.md b/docs/drafts/blog-201910-please-test-against-lts.md index 18d64631..a2c8b8c4 100644 --- a/docs/drafts/blog-201910-please-test-against-lts.md +++ b/docs/drafts/blog-201910-please-test-against-lts.md @@ -1,22 +1,22 @@ # Which versions of node should library authors test against? -tl;dr: we'd like to encourage package authors to make sure their Continuous Integration (CI) setup includes all supported Node.js "long-term support" (LTS) versions, as well as the Current stable release. +_tl;dr: we'd like to encourage package authors to make sure their Continuous Integration (CI) setup includes all supported Node.js "long-term support" (LTS) versions, as well as the Current stable release._ At the start of 2019, npm released a [list of top 1000 most downloaded packages](https://docs.google.com/spreadsheets/d/1lZDNYsLntwD2q9XaTw-XLuG0VpHH6cOV-Uoa7Y1aTSM/edit#gid=1745448509). We scanned that list to find that a large number of these packages have not been updated in over a year, but even if they have - they still did not include the latest Node.js LTS version (10.x at the time) in their Continuous Integration (CI) setup.1 -It is important to note, that CI providers, including Travis (the de facto standard2 in JavaScript package ecosystem) **might not be using LTS** as the default. This [will change soon](https://github.com/travis-ci/travis-build/pull/1747), however it is a good time to double check your testing configuration - in October, 2019 Node.js 12.x will become the active LTS version and 13.x will be released and at the end of December, 2019 Node.js 8.x will reach end-of-life. +It is important to note, that CI providers, including Travis (the de facto standard2 in JavaScript package ecosystem) **might not be using LTS** as the default. There is [work in progress to change this](https://github.com/travis-ci/travis-build/pull/1747), however it is a good time to double check your testing configuration - in October 2019 Node.js 12.x will become the active LTS version and 13.x will be released. At the end of December 2019 Node.js 8.x will reach end-of-life. ## Why The [release schedule](https://nodejs.org/en/about/releases/) of Node.js is set up to have a new release with breaking changes every 6 months. According to [semver](https://semver.org), each such release increments the major version number. Even-numbered releases (10, 12, etc) receive "long-term support" (30 months) and because of that only LTS versions are recommended to be used in production applications. -While library authors are free to chose any support policy3 they prefer, their libraries are likely to be used in up to 3 LTS versions that might be supported at any given time. We recommend to include all of these versions in the CI test matrix. At the time of writing this would mean Node.js 8 and 10. By January, 2020 this will become 10 and 12. +While library authors are free to chose any support policy3 they prefer, their libraries are likely to be used in one of up to 3 supported LTS versions. We recommend to include all of these versions in the CI test matrix. At the time of writing this would mean Node.js 8 and 10. By January 2020 this will become 10 and 12. -Odd-numbered (11, 13, etc) Node.js releases typically become unsupported after 6 months when a new even-numbered release is made available. While it is generally recommended that production applications do not use non-LTS Node.js versions, for library authors the recommendation is different - we'd like to encourage you to include the Current version (at the time of writing - 12, in January, 2020 - 13) in the test matrix, as this can serve as an advance warning for both - library authors and Node.js maintainers4. +Odd-numbered (11, 13, etc) Node.js releases typically become unsupported after 6 months when a new even-numbered release is made available. While it is generally recommended that production applications do not use non-LTS Node.js versions, for library authors the recommendation is different - we'd like to encourage you to include the Current version (at the time of writing - 12, in January 2020 - 13) in the test matrix, as this can serve as an advance warning for both - library authors and Node.js maintainers4. The above recommendation is for the minimal set of versions that should be supported - if it is an option at all, we'd like to encourage everyone to support older versions as well. -Additionally, while it is recommended to use (and therefore test in) the latest version of each major release line, you may want to additionally support some specific versions, e.g. 8.10.0 is used by AWS Lambda, even though 8.16.1 is available - if that is your support target, you might not have all the features added since then. +Additionally, while it is recommended to use the latest version of a major release line, you may want to support some specific versions, e.g. 8.10.0 is used by AWS Lambda, even though 8.16.1 is available. If that is one of your support targets you will be unable to use some of the newer features in 8.x and you should be checking for that in CI. ## How: setting up your `.travis.yml` @@ -32,7 +32,9 @@ node_js: When you use the keywords (`node`, `lts/*`), you will automatically start testing in new versions as they come out. This does, however, mean that you will also automatically _stop_ testing in versions that may still need to be supported. -Alternatively, you can use [Renovate](https://docs.renovatebot.com/node/) to automatically add new versions to your `.travis.yml`. +Alternatively, you can use [Renovate](https://docs.renovatebot.com/node/) to automatically open pull requests with new versions to your `.travis.yml` by adding `{ "travis": { "enabled": true } }` in your `renovate.json`. + +When you're testing with a Current (or nightly) Node.js version before it becomes LTS you can also enable [`allow_failures`](https://docs.travis-ci.com/user/build-matrix/#rows-that-are-allowed-to-fail) for it. ## How: dropping support for older Node.js versions From 5b571276a45029b60f69b9d647f38d36ec7bb89e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Fri, 4 Oct 2019 17:21:27 +0300 Subject: [PATCH 05/14] highlight "breaking change" --- docs/drafts/blog-201910-please-test-against-lts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/drafts/blog-201910-please-test-against-lts.md b/docs/drafts/blog-201910-please-test-against-lts.md index a2c8b8c4..a8e20df6 100644 --- a/docs/drafts/blog-201910-please-test-against-lts.md +++ b/docs/drafts/blog-201910-please-test-against-lts.md @@ -38,7 +38,7 @@ When you're testing with a Current (or nightly) Node.js version before it become ## How: dropping support for older Node.js versions -Maintaining an Open Source Software library can become a burden and it is unfeasible to expect that all versions of Node.js should be supported by library authors indefinitely. Changing the minimum Node.js version requirement is considered a breaking change and according to semver rules requires a major version of your package to be incremented. +Maintaining an Open Source Software library can become a burden and it is unfeasible to expect that all versions of Node.js should be supported by library authors indefinitely. Changing the minimum Node.js version requirement is considered a **breaking change** and according to semver rules requires a major version of your package to be incremented. You should also keep the [`engines` field](https://docs.npmjs.com/files/package.json#engines) in your `package.json` up to date to indicate supported versions. From f8f3b256afc13420ed2a95b59d636c19dd391b7a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Fri, 4 Oct 2019 17:27:59 +0300 Subject: [PATCH 06/14] add a footnote on accelerated node 8 EOL --- docs/drafts/blog-201910-please-test-against-lts.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/drafts/blog-201910-please-test-against-lts.md b/docs/drafts/blog-201910-please-test-against-lts.md index a8e20df6..8a1abb8a 100644 --- a/docs/drafts/blog-201910-please-test-against-lts.md +++ b/docs/drafts/blog-201910-please-test-against-lts.md @@ -4,15 +4,15 @@ _tl;dr: we'd like to encourage package authors to make sure their Continuous Int At the start of 2019, npm released a [list of top 1000 most downloaded packages](https://docs.google.com/spreadsheets/d/1lZDNYsLntwD2q9XaTw-XLuG0VpHH6cOV-Uoa7Y1aTSM/edit#gid=1745448509). We scanned that list to find that a large number of these packages have not been updated in over a year, but even if they have - they still did not include the latest Node.js LTS version (10.x at the time) in their Continuous Integration (CI) setup.1 -It is important to note, that CI providers, including Travis (the de facto standard2 in JavaScript package ecosystem) **might not be using LTS** as the default. There is [work in progress to change this](https://github.com/travis-ci/travis-build/pull/1747), however it is a good time to double check your testing configuration - in October 2019 Node.js 12.x will become the active LTS version and 13.x will be released. At the end of December 2019 Node.js 8.x will reach end-of-life. +It is important to note, that CI providers, including Travis (the de facto standard2 in JavaScript package ecosystem) **might not be using LTS** as the default. There is [work in progress to change this](https://github.com/travis-ci/travis-build/pull/1747), however it is a good time to double check your testing configuration - in October 2019 Node.js 12.x will become the active LTS version and 13.x will be released. At the end of December 2019 Node.js 8.x will reach end-of-life.3 ## Why The [release schedule](https://nodejs.org/en/about/releases/) of Node.js is set up to have a new release with breaking changes every 6 months. According to [semver](https://semver.org), each such release increments the major version number. Even-numbered releases (10, 12, etc) receive "long-term support" (30 months) and because of that only LTS versions are recommended to be used in production applications. -While library authors are free to chose any support policy3 they prefer, their libraries are likely to be used in one of up to 3 supported LTS versions. We recommend to include all of these versions in the CI test matrix. At the time of writing this would mean Node.js 8 and 10. By January 2020 this will become 10 and 12. +While library authors are free to chose any support policy4 they prefer, their libraries are likely to be used in one of up to 3 supported LTS versions. We recommend to include all of these versions in the CI test matrix. At the time of writing this would mean Node.js 8 and 10. By January 2020 this will become 10 and 12. -Odd-numbered (11, 13, etc) Node.js releases typically become unsupported after 6 months when a new even-numbered release is made available. While it is generally recommended that production applications do not use non-LTS Node.js versions, for library authors the recommendation is different - we'd like to encourage you to include the Current version (at the time of writing - 12, in January 2020 - 13) in the test matrix, as this can serve as an advance warning for both - library authors and Node.js maintainers4. +Odd-numbered (11, 13, etc) Node.js releases typically become unsupported after 6 months when a new even-numbered release is made available. While it is generally recommended that production applications do not use non-LTS Node.js versions, for library authors the recommendation is different - we'd like to encourage you to include the Current version (at the time of writing - 12, in January 2020 - 13) in the test matrix, as this can serve as an advance warning for both - library authors and Node.js maintainers5. The above recommendation is for the minimal set of versions that should be supported - if it is an option at all, we'd like to encourage everyone to support older versions as well. @@ -46,5 +46,6 @@ You should also keep the [`engines` field](https://docs.npmjs.com/files/package. 1. Out of top 1000 packages using Travis for CI, 315 had neither a variation of 10.x nor `lts/*` in their setup; ~150 of those had commits since 10.x was first released, of which ~120 had commits since 10.x became active LTS. 2. Out of top 1000 packages, 877 were pointing to GitHub repos with a `.travis.yml` file at the root in September 2019. -3. The [Package Maintenance Working Group](https://github.com/nodejs/package-maintenance/) is working on a way to [define your support levels](https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/PACKAGE-SUPPORT.md) - we welcome discussions and contributions. -4. The Node.js project also runs some smoke tests using The [Canary in the Goldmine tool](https://github.com/nodejs/citgm). +3. Originally, Node.js 8.x was mean to be supported until March 2020, however the scheduled had to be moved forward due to the OpenSSL version that it getting to [end-of-life in December 2019](https://developer.ibm.com/blogs/openssl-111-has-landed-in-nodejs-master-and-why-its-important-for-nodejs-lts-releases/). +4. The [Package Maintenance Working Group](https://github.com/nodejs/package-maintenance/) is working on a way to [define your support levels](https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/PACKAGE-SUPPORT.md) - we welcome discussions and contributions. +5. The Node.js project also runs some smoke tests using The [Canary in the Goldmine tool](https://github.com/nodejs/citgm). From 41d74ce107777d882f5e7208b88dbb96cade24eb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Fri, 4 Oct 2019 17:29:50 +0300 Subject: [PATCH 07/14] fix typos --- docs/drafts/blog-201910-please-test-against-lts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/drafts/blog-201910-please-test-against-lts.md b/docs/drafts/blog-201910-please-test-against-lts.md index 8a1abb8a..28a975a4 100644 --- a/docs/drafts/blog-201910-please-test-against-lts.md +++ b/docs/drafts/blog-201910-please-test-against-lts.md @@ -46,6 +46,6 @@ You should also keep the [`engines` field](https://docs.npmjs.com/files/package. 1. Out of top 1000 packages using Travis for CI, 315 had neither a variation of 10.x nor `lts/*` in their setup; ~150 of those had commits since 10.x was first released, of which ~120 had commits since 10.x became active LTS. 2. Out of top 1000 packages, 877 were pointing to GitHub repos with a `.travis.yml` file at the root in September 2019. -3. Originally, Node.js 8.x was mean to be supported until March 2020, however the scheduled had to be moved forward due to the OpenSSL version that it getting to [end-of-life in December 2019](https://developer.ibm.com/blogs/openssl-111-has-landed-in-nodejs-master-and-why-its-important-for-nodejs-lts-releases/). +3. Originally, Node.js 8.x was mean to be supported until March 2020, however the schedule had to be moved forward due to the OpenSSL version that it uses getting to [end-of-life in December 2019](https://developer.ibm.com/blogs/openssl-111-has-landed-in-nodejs-master-and-why-its-important-for-nodejs-lts-releases/). 4. The [Package Maintenance Working Group](https://github.com/nodejs/package-maintenance/) is working on a way to [define your support levels](https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/PACKAGE-SUPPORT.md) - we welcome discussions and contributions. 5. The Node.js project also runs some smoke tests using The [Canary in the Goldmine tool](https://github.com/nodejs/citgm). From 7293bcddb37b035857388534fdc56cbc828ee4ce Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Fri, 4 Oct 2019 17:34:27 +0300 Subject: [PATCH 08/14] note the snowball effect of a major bump --- docs/drafts/blog-201910-please-test-against-lts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/drafts/blog-201910-please-test-against-lts.md b/docs/drafts/blog-201910-please-test-against-lts.md index 28a975a4..2c5e0fc1 100644 --- a/docs/drafts/blog-201910-please-test-against-lts.md +++ b/docs/drafts/blog-201910-please-test-against-lts.md @@ -38,7 +38,7 @@ When you're testing with a Current (or nightly) Node.js version before it become ## How: dropping support for older Node.js versions -Maintaining an Open Source Software library can become a burden and it is unfeasible to expect that all versions of Node.js should be supported by library authors indefinitely. Changing the minimum Node.js version requirement is considered a **breaking change** and according to semver rules requires a major version of your package to be incremented. +Maintaining an Open Source Software library can become a burden and it is unfeasible to expect that all versions of Node.js should be supported by library authors indefinitely. Changing the minimum Node.js version requirement is considered a **breaking change** and according to semver rules requires a major version of your package to be incremented. Still, this decision should not be taken lightly, as bumping a major version of your package can have a snowball effect on the package dependents and the rest of the ecosystem. You should also keep the [`engines` field](https://docs.npmjs.com/files/package.json#engines) in your `package.json` up to date to indicate supported versions. From eccb52ab0bb19a8d006bd69d1066d6f89d48724f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Fri, 4 Oct 2019 17:40:46 +0300 Subject: [PATCH 09/14] note extra budern to backport --- docs/drafts/blog-201910-please-test-against-lts.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/drafts/blog-201910-please-test-against-lts.md b/docs/drafts/blog-201910-please-test-against-lts.md index 2c5e0fc1..496fe72d 100644 --- a/docs/drafts/blog-201910-please-test-against-lts.md +++ b/docs/drafts/blog-201910-please-test-against-lts.md @@ -38,7 +38,9 @@ When you're testing with a Current (or nightly) Node.js version before it become ## How: dropping support for older Node.js versions -Maintaining an Open Source Software library can become a burden and it is unfeasible to expect that all versions of Node.js should be supported by library authors indefinitely. Changing the minimum Node.js version requirement is considered a **breaking change** and according to semver rules requires a major version of your package to be incremented. Still, this decision should not be taken lightly, as bumping a major version of your package can have a snowball effect on the package dependents and the rest of the ecosystem. +Maintaining an Open Source Software library can become a burden and it is unfeasible to expect that all versions of Node.js should be supported by library authors indefinitely. Changing the minimum Node.js version requirement is considered a **breaking change** and according to semver rules requires a major version of your package to be incremented. + +Still, this decision should not be taken lightly, as bumping a major version of your package can have a snowball effect on the package dependents and the rest of the ecosystem. This can also result in extra work to backport security patches to older versions, if the package consumers are unable to upgrade fast enough. You should also keep the [`engines` field](https://docs.npmjs.com/files/package.json#engines) in your `package.json` up to date to indicate supported versions. From 72716522e9a17366ff845e38321556a86a8705f7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Bly=C5=BE=C4=97?= Date: Fri, 4 Oct 2019 17:41:48 +0300 Subject: [PATCH 10/14] fix typo Co-Authored-By: Vincent Weevers --- docs/drafts/blog-201910-please-test-against-lts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/drafts/blog-201910-please-test-against-lts.md b/docs/drafts/blog-201910-please-test-against-lts.md index 496fe72d..9556e3c0 100644 --- a/docs/drafts/blog-201910-please-test-against-lts.md +++ b/docs/drafts/blog-201910-please-test-against-lts.md @@ -48,6 +48,6 @@ You should also keep the [`engines` field](https://docs.npmjs.com/files/package. 1. Out of top 1000 packages using Travis for CI, 315 had neither a variation of 10.x nor `lts/*` in their setup; ~150 of those had commits since 10.x was first released, of which ~120 had commits since 10.x became active LTS. 2. Out of top 1000 packages, 877 were pointing to GitHub repos with a `.travis.yml` file at the root in September 2019. -3. Originally, Node.js 8.x was mean to be supported until March 2020, however the schedule had to be moved forward due to the OpenSSL version that it uses getting to [end-of-life in December 2019](https://developer.ibm.com/blogs/openssl-111-has-landed-in-nodejs-master-and-why-its-important-for-nodejs-lts-releases/). +3. Originally, Node.js 8.x was meant to be supported until March 2020, however the schedule had to be moved forward due to the OpenSSL version that it uses getting to [end-of-life in December 2019](https://developer.ibm.com/blogs/openssl-111-has-landed-in-nodejs-master-and-why-its-important-for-nodejs-lts-releases/). 4. The [Package Maintenance Working Group](https://github.com/nodejs/package-maintenance/) is working on a way to [define your support levels](https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/PACKAGE-SUPPORT.md) - we welcome discussions and contributions. 5. The Node.js project also runs some smoke tests using The [Canary in the Goldmine tool](https://github.com/nodejs/citgm). From e0e56a4d3d1d8eb385c3219c43911c7e03d049d7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Bly=C5=BE=C4=97?= Date: Fri, 4 Oct 2019 17:42:22 +0300 Subject: [PATCH 11/14] take pride in CITGM Co-Authored-By: Vincent Weevers --- docs/drafts/blog-201910-please-test-against-lts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/drafts/blog-201910-please-test-against-lts.md b/docs/drafts/blog-201910-please-test-against-lts.md index 9556e3c0..ac150caa 100644 --- a/docs/drafts/blog-201910-please-test-against-lts.md +++ b/docs/drafts/blog-201910-please-test-against-lts.md @@ -50,4 +50,4 @@ You should also keep the [`engines` field](https://docs.npmjs.com/files/package. 2. Out of top 1000 packages, 877 were pointing to GitHub repos with a `.travis.yml` file at the root in September 2019. 3. Originally, Node.js 8.x was meant to be supported until March 2020, however the schedule had to be moved forward due to the OpenSSL version that it uses getting to [end-of-life in December 2019](https://developer.ibm.com/blogs/openssl-111-has-landed-in-nodejs-master-and-why-its-important-for-nodejs-lts-releases/). 4. The [Package Maintenance Working Group](https://github.com/nodejs/package-maintenance/) is working on a way to [define your support levels](https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/PACKAGE-SUPPORT.md) - we welcome discussions and contributions. -5. The Node.js project also runs some smoke tests using The [Canary in the Goldmine tool](https://github.com/nodejs/citgm). +5. The Node.js project also runs smoke tests using The [Canary in the Goldmine tool](https://github.com/nodejs/citgm). From 608bd65d03e3e6a66c402e831f052d28387fa79c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Bly=C5=BE=C4=97?= Date: Thu, 10 Oct 2019 23:36:18 +0300 Subject: [PATCH 12/14] Update docs/drafts/blog-201910-please-test-against-lts.md Co-Authored-By: Joel Chen --- docs/drafts/blog-201910-please-test-against-lts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/drafts/blog-201910-please-test-against-lts.md b/docs/drafts/blog-201910-please-test-against-lts.md index ac150caa..94cdeac0 100644 --- a/docs/drafts/blog-201910-please-test-against-lts.md +++ b/docs/drafts/blog-201910-please-test-against-lts.md @@ -10,7 +10,7 @@ It is important to note, that CI providers, including Travis (the de facto stand The [release schedule](https://nodejs.org/en/about/releases/) of Node.js is set up to have a new release with breaking changes every 6 months. According to [semver](https://semver.org), each such release increments the major version number. Even-numbered releases (10, 12, etc) receive "long-term support" (30 months) and because of that only LTS versions are recommended to be used in production applications. -While library authors are free to chose any support policy4 they prefer, their libraries are likely to be used in one of up to 3 supported LTS versions. We recommend to include all of these versions in the CI test matrix. At the time of writing this would mean Node.js 8 and 10. By January 2020 this will become 10 and 12. +While library authors are free to choose any support policy4 they prefer, their libraries are likely to be used in one of up to 3 supported LTS versions. We recommend to include all of these versions in the CI test matrix. At the time of writing this would mean Node.js 8 and 10. By January 2020 this will become 10 and 12. Odd-numbered (11, 13, etc) Node.js releases typically become unsupported after 6 months when a new even-numbered release is made available. While it is generally recommended that production applications do not use non-LTS Node.js versions, for library authors the recommendation is different - we'd like to encourage you to include the Current version (at the time of writing - 12, in January 2020 - 13) in the test matrix, as this can serve as an advance warning for both - library authors and Node.js maintainers5. From 06238dc9e38b98a038c15e324dc80f63ae5a5c90 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Sat, 12 Oct 2019 11:50:00 +0300 Subject: [PATCH 13/14] update title, link to list of reviewers, style tweaks --- docs/drafts/blog-201910-please-test-against-lts.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/drafts/blog-201910-please-test-against-lts.md b/docs/drafts/blog-201910-please-test-against-lts.md index 94cdeac0..1016cb78 100644 --- a/docs/drafts/blog-201910-please-test-against-lts.md +++ b/docs/drafts/blog-201910-please-test-against-lts.md @@ -1,6 +1,6 @@ -# Which versions of node should library authors test against? +# Choosing the Node.js versions for your CI tests (hint: use LTS) -_tl;dr: we'd like to encourage package authors to make sure their Continuous Integration (CI) setup includes all supported Node.js "long-term support" (LTS) versions, as well as the Current stable release._ +_tl;dr: we'd like to encourage package authors to make sure their Continuous Integration (CI) setup includes **all supported Node.js "long-term support" (LTS) versions**, as well as the Current stable release._ At the start of 2019, npm released a [list of top 1000 most downloaded packages](https://docs.google.com/spreadsheets/d/1lZDNYsLntwD2q9XaTw-XLuG0VpHH6cOV-Uoa7Y1aTSM/edit#gid=1745448509). We scanned that list to find that a large number of these packages have not been updated in over a year, but even if they have - they still did not include the latest Node.js LTS version (10.x at the time) in their Continuous Integration (CI) setup.1 @@ -20,7 +20,7 @@ Additionally, while it is recommended to use the latest version of a major relea ## How: setting up your `.travis.yml` -Travis uses [`nvm`](https://github.com/nvm-sh/nvm) to install node, so you can use any version or keyword it supports in your [`.travis.yml`](https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#specifying-nodejs-versions). This means that your setup should look something like this: +Travis uses [`nvm`](https://github.com/nvm-sh/nvm) to install Node.js, so you can use any version or keyword it supports in your [`.travis.yml`](https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#specifying-nodejs-versions). This means that your setup should look something like this: ``` language: node_js @@ -51,3 +51,5 @@ You should also keep the [`engines` field](https://docs.npmjs.com/files/package. 3. Originally, Node.js 8.x was meant to be supported until March 2020, however the schedule had to be moved forward due to the OpenSSL version that it uses getting to [end-of-life in December 2019](https://developer.ibm.com/blogs/openssl-111-has-landed-in-nodejs-master-and-why-its-important-for-nodejs-lts-releases/). 4. The [Package Maintenance Working Group](https://github.com/nodejs/package-maintenance/) is working on a way to [define your support levels](https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/PACKAGE-SUPPORT.md) - we welcome discussions and contributions. 5. The Node.js project also runs smoke tests using The [Canary in the Goldmine tool](https://github.com/nodejs/citgm). + +Thanks to [all the reviewers](https://github.com/nodejs/package-maintenance/pull/260)! From 6430fc2c0eecbe8af28e2404c9a64f379524cf14 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Sat, 12 Oct 2019 11:51:21 +0300 Subject: [PATCH 14/14] add notes on other tools --- docs/drafts/blog-201910-please-test-against-lts.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/drafts/blog-201910-please-test-against-lts.md b/docs/drafts/blog-201910-please-test-against-lts.md index 1016cb78..dff1170c 100644 --- a/docs/drafts/blog-201910-please-test-against-lts.md +++ b/docs/drafts/blog-201910-please-test-against-lts.md @@ -36,6 +36,14 @@ Alternatively, you can use [Renovate](https://docs.renovatebot.com/node/) to aut When you're testing with a Current (or nightly) Node.js version before it becomes LTS you can also enable [`allow_failures`](https://docs.travis-ci.com/user/build-matrix/#rows-that-are-allowed-to-fail) for it. +## How: other CI tools + +- Appveyor, at the time of writing, has Node.js 8.x installed by default. [They also allow testing in multiple Node.js versions](https://www.appveyor.com/docs/lang/nodejs-iojs/). You can use the `Install-Product node ''` command to install the latest (Current) available release. You should verify your configuration to include all the other LTS versions as well. +- Circle CI requires you to explicitly list the docker images you want to use for testing. The [images provided by Circle CI on Docker Hub](https://hub.docker.com/r/circleci/node/tags) do have aliases such as `lts` or `current`, they even provide a [ChakraCore](https://github.com/nodejs/node-chakracore) based image. You should make sure your configured list is up to date. +- Github Actions includes all LTS versions and the Current version in their [Node.js starter workflow](https://github.com/actions/starter-workflows/blob/master/ci/node.js.yml), however you will need to maintain that list to keep it up to date. There is an open issue discussing the [options for matrix aliases](https://github.com/actions/setup-node/issues/26) with the `setup-node` action and a PR to introduce [keywords for individual versions](https://github.com/actions/setup-node/pull/58). + +Please leave a comment with other tips! + ## How: dropping support for older Node.js versions Maintaining an Open Source Software library can become a burden and it is unfeasible to expect that all versions of Node.js should be supported by library authors indefinitely. Changing the minimum Node.js version requirement is considered a **breaking change** and according to semver rules requires a major version of your package to be incremented.