docs: move to the new LTS accross all projects #350
Conversation
ghost
assigned 
|
This will enable us to do things such as libp2p/js-libp2p-crypto#130 |
daviddias
requested review from
achingbrain,
alanshaw,
jacobheun,
vasco-santos,
hugomrdias and
vmx
CONTRIBUTING_JS.md
Outdated
| @@ -132,9 +132,14 @@ Always run tests before pushing and PR'ing your code. | |||
|
|
|||
| #### Supported Versions | |||
|
|
|||
| IPFS projects support both the Current and Active LTS versions of Node.js. Please see [nodejs.org](https://nodejs.org/) for what these currently are. | |||
| The IPFS JavaScript projects follow the LTS of Node.js and respective npm version that gets installed with Node.js. Please consult [nodejs.org](https://nodejs.org/) for LTS timeline. Today these are: | |||
There was a problem hiding this comment.
I don't find this clear enough. What is "LTS of Node.js"? Reading the linked issue I think you mean "only the most recent active LTS of Node.js"?
There was a problem hiding this comment.
Good point, I've updated it now :)
|
|
||
| Browser code may be transpiled using Babel to take advantage of the latest JavaScript features. | ||
| ``` | ||
| » node -v |
There was a problem hiding this comment.
Perhpas doing a date -u +"%Y-%m-%dT%H:%M:%SZ" first, so that it is clear what "today" means?
|
@vmx applied your review |
|
@victorbjelkholm once this is merged, can you help this effort by creating the automated PRs that update the package.json and the badges to reference the new base supported versions? |
|
@diasdavid Just to double check This change is about dropping Node 8.x support, right? Perhaps you can mention that when you squash merge the commits. We are not really moving to a new LTS, we are just dropping an older one. |
|
That's a fair way to describe it. I would say that we are moving to a new baseline, which is the new LTS |
| » date -u +"%Y-%m-%dT%H:%M:%SZ" | ||
| 2018-10-31T09:06:36Z | ||
| » node -v | ||
| v10.13.0 |
There was a problem hiding this comment.
Are we going to have to update this with every LTS point release? The idea behind saying 'Look at the node website for what the current LTS is' was to reduce the amount of busywork we have to do.
There was a problem hiding this comment.
I agree, we should not list the version here, it's easy to look up.
|
I don't think it's a good idea to drop support for an Active LTS version (node 8). We should stop actively supporting it when it goes into maintenance. As users start integrating the projects more and more into production applications, losing that level of support is going to be very detrimental to their projects. |
CONTRIBUTING_JS.md
Outdated
| @@ -132,9 +132,16 @@ Always run tests before pushing and PR'ing your code. | |||
|
|
|||
| #### Supported Versions | |||
|
|
|||
| IPFS projects support both the Current and Active LTS versions of Node.js. Please see [nodejs.org](https://nodejs.org/) for what these currently are. | |||
| The IPFS JavaScript projects follow the most recent LTS of Node.js and respective npm version that gets installed with Node.js. Please consult [nodejs.org](https://nodejs.org/) for LTS timeline. Today these are: | |||
There was a problem hiding this comment.
"work with"/"run on" instead of "follow"?
As a project(s) that's deemed to be alpha/experimental/unstable I think it's reasonable to switch to the new LTS. It'll save us a bunch of admin supporting both, allow us to take advantage of the new APIs and FWIW I don't think that the environments IPFS/libp2p supports need necessarily be tied to the same timelines that Node.js gives to it's releases. |
|
I'm in support of @alanshaw point. It is a tough decision and one that we should not make lightly or repeatedly but for this moment in time, it will provide a feature and speed boost that will benefit the project which will then benefit the users. |
|
4 (including me) out of 7 have approved this PR, I believe we have a quorum :) |
|
I agree it will save a lot of time up front, and we'll be able to remove testing on node8 from jenkins which will save a lot of bandwidth. I would recommend we set some review milestones to revisit this in the IPFS roadmap to v1.0 as that gets closer to happening. Reducing upgrade cycles for projects from 18 months to 12 months is pretty brutal for large applications, or applications with limited teams. That's potentially a pretty significant maintenance cost for them, especially if we're using new features in the latest LTS versions. |
|
I would sincerely recommend against this approach. Not only Node 8 is still Active LTS, but it will be supported for more than one year. See https://github.com/nodejs/Release#release-schedule for more details. I would also remember that dropping support for a Node.js release line is typically a semver-major change. |
No description provided.