Update documentation #12
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,46 +1,58 @@ | ||
| # Auto-updated Node.js version matrix in Travis CI | ||
|
|
||
| - This repository is managed by the [Package Maintenance Working Group](https:/nodejs/package-maintenance), see [Governance](https:/nodejs/package-maintenance/blob/master/Governance.md). | ||
| - Read more about [Shared Build Configurations in Travis CI](https://docs.travis-ci.com/user/build-config-imports/). | ||
|
|
||
| Import configurations from this repository into your `.travis.yml` to automatically start testing in new versions of Node.js as they get released. | ||
|
|
||
| ## Usage | ||
|
|
||
| In your `.travis.yml`, replace the `node_js` section with the following: | ||
|
|
||
| ``` | ||
| import: | ||
| - nodejs/ci-config-travis:lts/gte-10.yml | ||
| # ^ ^ | ||
| # | | | ||
| # | ·---------- Miminum version | ||
| # ·------------------ Upgrade policy | ||
| # i.e. include all LTS Node.js releases, starting with version 10.x | ||
| ``` | ||
|
|
||
| Depending on the support policy of your library/application, you can choose when and which versions get added to your test matrix. | ||
|
|
||
| Once added to the list, the Long Term Support (LTS) versions will never get removed from the list, i.e. you will need to take explicit action to change the minimum version you're importing (note: when you increase the minimum version requirements, you should also bump the major version of your package, to indicate breaking changes according to [semver](https://semver.org/)). | ||
|
|
||
| This repository offers three upgrade policies: | ||
|
|
||
| - **[`all`](./all)** - new major releases get added as they are released, they never get removed | ||
| - **[`lts`](./lts)** - new major releases get added as they are released, non-LTS releases get removed when their support lifetime ends, LTS versions never get removed | ||
| - **[`lts/strict`](./lts/strict)** - new major releases get added as they reach LTS status, they never get removed | ||
|
|
||
| ### Upgrade timeline | ||
|
|
||
| For actual release dates, please check the Node.js [Release Working Group](https:/nodejs/Release/#release-schedule) repository. | ||
|
|
||
| This is an example of which versions would be available in each of the files on a certain date: | ||
|
|
||
| | | `all/gte-10.yml` | `lts/gte-10.yml` | `lts/strict/gte-10.yml` | Notes | ||
| |-----------------------|--------------------------------|-------------------------|-------------------------|------- | ||
| | Jul, 2020 | 10, 11, 12, 13, 14 | 10, 12, 14 | 10, 12 | | ||
| | Nov, 2020 | 10, 11, 12, 13, 14, 15 | 10, 12, 14, 15 | 10, 12, 14 | In Oct, 2020 v14 reaches LTS and v15 is released | ||
| | May, 2021 | 10, 11, 12, 13, 14, 15, 16 | 10, 12, 14, 15, 16 | 10, 12, 14 | In Apr, 2021 v10 reaches EOL and v16 is released | ||
| | Jul, 2021 | 10, 11, 12, 13, 14, 15, 16 | 10, 12, 14, 16 | 10, 12, 14 | On 1/Jun/2021, v15 reaches EOL and ⚠️ is removed from `lts` policy files (`lts/strict` never has this version included and `all` keeps it) | ||
| | Nov, 2021 | 10, 11, 12, 13, 14, 15, 16, 17 | 10, 12, 14, 16, 17 | 10, 12, 14, 16 | In Oct, 2021 V16 reaches LTS and v17 should be released | ||
|
|
||
|
|
||
| ## Including the minimum supported version | ||
|
|
||
| The shared configurations only define a list of major versions, which means Travis CI will execute your tests in the _latest_ version of each major release line. If you intend your code to work in earlier versions of that release line, you _should_ explicitly include the earliest version you support in your test matrix, e.g. append the following in your `.travis.yml`: | ||
|
|
||
|
|
||
| ``` | ||
| node_js: | ||
| - "10.0.0" | ||
| ``` | ||
|
|
||
| This will ensure that you do not accidentally use features added in v10.1+, as they would be considered breaking changes for the consumers of your library. | ||
|
|
||
| Should you chose to only support the latest version of any major release line, there currently is no supported way to define that via the `engines` field in your `package.json`, however you could communicate this using [Document support levels](https:/nodejs/package-maintenance/blob/master/docs/PACKAGE-SUPPORT.md) (i.e. the `support` field or alternative locations). | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,44 @@ | ||
| # Travis CI imports - Node.js upgrade policy: `all` | ||
|
|
||
| Import configurations from this folder into your `.travis.yml` to automatically start testing in new versions of Node.js as they get released. | ||
|
|
||
| Other upgrade policies: | ||
|
|
||
| - [`lts`](../lts) - new major releases get added as they are released, non-LTS releases get removed when their support lifetime ends, LTS versions never get removed | ||
| - [`lts/strict`](../lts/strict) - new major releases get added as they reach LTS status, they never get removed | ||
|
|
||
|
|
||
| ## Usage example | ||
|
|
||
| In your `.travis.yml`, replace the `node_js` section with the following: | ||
|
|
||
| ``` | ||
| import: | ||
| - nodejs/ci-config-travis:all/gte-14.yml | ||
| ``` | ||
|
|
||
| - Travis will use the latest version of each release line in the list | ||
| - New major Node.js versions, greater or equal to v14.0.0, will be added to the list as soon as they are released | ||
| - Once added, versions will never be removed from the list | ||
|
|
||
| The shared configurations only define a list of major versions, which means Travis CI will execute your tests in the _latest_ version of each major release line. If you intend your code to work in earlier versions of that release line, you _should_ explicitly include the earliest version you support in your test matrix, e.g. append the following in your `.travis.yml`: | ||
|
|
||
| ``` | ||
| node_js: | ||
| - "10.0.0" | ||
| ``` | ||
|
|
||
|
|
||
| ### Upgrade timeline | ||
|
|
||
| For actual release dates, please check the Node.js [Release Working Group](https:/nodejs/Release/#release-schedule) repository. | ||
|
|
||
| This is an example of which versions would be available in each of the files on a certain date: | ||
|
|
||
| | | `all/gte-10.yml` | Notes | ||
| |-----------------------|--------------------------------|------- | ||
| | Jul, 2020 | 10, 11, 12, 13, 14 | | ||
| | Nov, 2020 | 10, 11, 12, 13, 14, 15 | In Oct, 2020 v14 reaches LTS and v15 is released | ||
| | May, 2021 | 10, 11, 12, 13, 14, 15, 16 | In Apr, 2021 v10 reaches EOL and v16 is released | ||
| | Jul, 2021 | 10, 11, 12, 13, 14, 15, 16 | On 1/Jun/2021, v15 reaches EOL | ||
| | Nov, 2021 | 10, 11, 12, 13, 14, 15, 16, 17 | In Oct, 2021 V16 reaches LTS and v17 should be released |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,47 @@ | ||
| # Travis CI imports - Node.js upgrade policy: `lts` | ||
|
|
||
| Import configurations from this folder into your `.travis.yml` to automatically start testing in new versions of Node.js as they get released. Long Term Support (LTS) versions will never get removed from these configurations. Non-LTS versions will get removed when they reach End-of-Life and are no longer support. | ||
|
|
||
| Please mind that when you remove the supported Node.js versions in _your library_, according to [semver](https://semver.org/), you should be publishing a new major release. This particular upgrade policy is designed for libraries that support _only LTS_ releases, even though non-LTS releases may appear in their test matrix, i.e. a removal of non-LTS release does not imply a semver breaking change if that non-LTS release was not officially support. | ||
|
|
||
| Other upgrade policies: | ||
|
|
||
| - [`all`](../all) - new major releases get added as they are released, they never get removed | ||
| - [`lts/strict`](../lts/strict) - new major releases get added as they reach LTS status, they never get removed | ||
|
|
||
|
|
||
| ## Usage example | ||
|
|
||
| In your `.travis.yml`, replace the `node_js` section with the following: | ||
|
|
||
| ``` | ||
| import: | ||
| - nodejs/ci-config-travis:lts/gte-10.yml | ||
| ``` | ||
|
|
||
| - Travis CI will use the latest version of each release line in the list | ||
| - New major Node.js versions, greater or equal to v10.0.0, will be added to the list as soon as they are released | ||
| - Once added, LTS versions will never be removed. Non-LTS versions will be removed when they reach their lifetime. | ||
| - Note that if your policy is to only support LTS versions, then removing the non-LTS version in your test matrix is not a breaking change, as the non-LTS version was never supported (it was only used for test purposes). | ||
|
|
||
| The shared configurations only define a list of major versions, which means Travis CI will execute your tests in the _latest_ version of each major release line. If you intend your code to work in earlier versions of that release line, you _should_ explicitly include the earliest version you support in your test matrix, e.g. append the following in your `.travis.yml`: | ||
|
|
||
| ``` | ||
| node_js: | ||
| - "10.0.0" | ||
| ``` | ||
|
|
||
|
|
||
| ### Upgrade timeline | ||
|
|
||
| For actual release dates, please check the Node.js [Release Working Group](https:/nodejs/Release/#release-schedule) repository. | ||
|
|
||
| This is an example of which versions would be available in each of the files on a certain date: | ||
|
|
||
| | | `lts/gte-10.yml` | Notes | ||
| |-----------------------|-------------------------|------- | ||
| | Jul, 2020 | 10, 12, 14 | | ||
| | Nov, 2020 | 10, 12, 14, 15 | In Oct, 2020 v14 reaches LTS and v15 is released | ||
| | May, 2021 | 10, 12, 14, 15, 16 | In Apr, 2021 v10 reaches EOL and v16 is released | ||
| | Jul, 2021 | 10, 12, 14, 16 | On 1/Jun/2021, v15 reaches EOL and ⚠️ is removed from `lts` policy files | ||
| | Nov, 2021 | 10, 12, 14, 16, 17 | In Oct, 2021 V16 reaches LTS and v17 should be released |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,44 @@ | ||
| # Travis CI imports - Node.js upgrade policy: `lts/strict` | ||
|
|
||
| Import configurations from this folder into your `.travis.yml` to automatically start testing in new versions of Node.js as they reach Long Term Support (LTS) status. | ||
|
|
||
| Other upgrade policies: | ||
|
|
||
| - [`all`](../../all) - new major releases get added as they are released, they never get removed | ||
| - [`lts`](../../lts) - new major releases get added as they are released, non-LTS releases get removed when their support lifetime ends, LTS versions never get removed | ||
|
|
||
|
|
||
| ## Usage example | ||
|
|
||
| In your `.travis.yml`, replace the `node_js` section with the following: | ||
|
|
||
| ``` | ||
| import: | ||
| - nodejs/ci-config-travis:lts/strict/gte-10.yml | ||
| ``` | ||
|
|
||
| - Travis will use the latest version of each release line in the list | ||
| - New major Node.js versions, greater or equal to v10.0.0, will be added to the list as soon as they achieve LTS status (i.e. ~6 months after they are first released) | ||
| - Once added, versions will never be removed from the list | ||
|
|
||
| The shared configurations only define a list of major versions, which means Travis CI will execute your tests in the _latest_ version of each major release line. If you intend your code to work in earlier versions of that release line, you _should_ explicitly include the earliest version you support in your test matrix, e.g. append the following in your `.travis.yml`: | ||
|
|
||
| ``` | ||
| node_js: | ||
| - "10.0.0" | ||
| ``` | ||
|
|
||
|
|
||
| ### Upgrade timeline | ||
|
|
||
| For actual release dates, please check the Node.js [Release Working Group](https:/nodejs/Release/#release-schedule) repository. | ||
|
|
||
| This is an example of which versions would be available in each of the files on a certain date: | ||
|
|
||
| | | `lts/strict/gte-10.yml` | Notes | ||
| |-----------------------|-------------------------|------- | ||
| | Jul, 2020 | 10, 12 | | ||
| | Nov, 2020 | 10, 12, 14 | In Oct, 2020 v14 reaches LTS and v15 is released | ||
| | May, 2021 | 10, 12, 14 | In Apr, 2021 v10 reaches EOL and v16 is released | ||
| | Jul, 2021 | 10, 12, 14 | On 1/Jun/2021, v15 reaches EOL | ||
| | Nov, 2021 | 10, 12, 14, 16 | In Oct, 2021 V16 reaches LTS and v17 should be released |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering if there is value in adding support for the other aliases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered that, but they'd have identical contents with the ones here, given the "we won't remove versions" guarantee.