Blog: please test in LTS #260
Conversation
| @@ -0,0 +1,50 @@ | |||
| # Which versions of node should library authors test against? | |||
There was a problem hiding this comment.
I need a better title for this :)
There was a problem hiding this comment.
How about
Testing for success -How to choose which versions of Node.js to test your package against?
There was a problem hiding this comment.
Choosing the Node.js versions for your CI tests (hint: use LTS)
Maybe leave out CI.
I think Michael's suggestion also kind of makes sense - just ideally we'd shorten that.
There was a problem hiding this comment.
@dominykas I'm happy with your suggestion or if it's not too long "Test for Success - hoosing the Node.js versions for your CI tests (hint: use LTS)'
|
Our testing guidelines and CI/CD guidelines are still drafts - do we feel we should still mention them in the blog? |
There was a problem hiding this comment.
I think we should touch two topics that are correlated and important:
- bumping major for dropping old versions of Node.js can have a snowball effect on a toolchain. If an utility module bump the major for dropping the support of an old Node.js versions, it would take all the chain of dependencies to drop the support for that Node version. The deeper a module is on the dependency chain, the worse this become.
- Maintaining multiple lines could be a burden, but it might be needed because of users of "old" versions prefer to not bump the major at a given time and a new security vulnerability arises and it needs to be backported.
|
|
||
| ## 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. |
There was a problem hiding this comment.
I would put breaking change in bold, and ideally make an example.
|
|
||
| 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.<sup>1</sup> | ||
|
|
||
| It is important to note, that CI providers, including Travis (the de facto standard<sup>2</sup> 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. |
There was a problem hiding this comment.
I think it's better to explain why 8.x is going end-of-life at the end of 2019 instead of March 2020, i.e. because the version of OpenSSL that it uses goes end-of-life.
There was a problem hiding this comment.
Is the IBM blogpost I linked to the canonical one or is there something better somewhere?
Added that as a footnote, as this blogpost is not about that.
Co-Authored-By: Vincent Weevers <[email protected]>
Co-Authored-By: Vincent Weevers <[email protected]>
mhdawson
added
the
package-maintenance-agenda
|
Discussed in the package maintenance meeting. Unless there are objections by the end of the week, we'll plan to send it out. @nodejs/package-maintenance . Would be good to get a few more approvals as well. We've lined up having it be published on the Node.js medium page. |
Co-Authored-By: Joel Chen <[email protected]>
|
@dominykas lets sync up tomorrow, looks like this is ready to go out. |
|
👍 |
|
@mhdawson let's wait till Monday, I'll see if I can work a mention of other providers in. |
|
@dominykas sounds good, let me know when you think its ready. |
|
The final edits will be made in a Google Doc (I'll be slightly tweaking the wording because Node.js 12 and 13 are out): https://docs.google.com/document/d/1Y8bp64xeCimMg5KsJZ-0wV66ufmxi3Tv09B8cTQ2I40/edit#heading=h.swmifn7gchjq |
|
This is now published: https://medium.com/@nodejs/choosing-the-node-js-versions-for-your-ci-tests-hint-use-lts-89b67f68d7ca @nodejs/package-maintenance please spread the word :) |
dominykas
removed
the
package-maintenance-agenda
Closes #204
Closes #200
This is a draft - I still have to write up the "automated updates" section, but I think the outline is there.Added a short paragraph, not a full section.I'll probably also include some more numbers from the scan of the top 1000.I'll see if I have time to investigate and mention other CI systems (although GH actions does the right thing, at least in their template) - I think we should try to move and get this published sooner rather than later, in anticipation of the new LTS.Currently leaning against writing up other CI systems - 90% of the top1k use Travis, it also likely the case throughout the ecosystem - not sure which other providers should be included anyways. Possibly we could better address that via CI/CD guidelines?