Skip to content

Dropping support for node<10.x? #2865

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
brianc opened this issue Nov 22, 2022 · 7 comments
Open

Dropping support for node<10.x? #2865

brianc opened this issue Nov 22, 2022 · 7 comments

Comments

@brianc
Copy link
Owner

brianc commented Nov 22, 2022

Want to start a discussion around dropping support for node 8.x. It's been out of LTS for many years at this point. I just hit an error building nothing but docs here due to what looks to be an incompatibility w/ the system version of python and version of node-gyp. I have to regularly reject dependabot PRs because they're bumping versions (of devDependencies) which aren't compatible w/ such an old version of node. I've always tried to keep this lib as backwards compatible as possible because forcing breaking changes on production code bases is something I've been on the receiving end of enough times that I just don't want to inflict that pain on anyone unless absolutely nessessary. That being said...node v8.x has been end of life for almost 3 years now & I'd like to move things forward, even a little bit, on this end.

@brianc
Copy link
Owner Author

brianc commented Nov 22, 2022

Along with that I plan to update the documentation (new site in the works!) to be async/await first with a mention to callbacks still being available. I don't see a time in the near future when I'll drop callback support...but again its been ages since async/await has shipped natively w/ node & I want to move things forward, ever slowly and carefully, into the 2020s. 😄 I think having callback examples throughout the documentation along w/ self-executing async functions instead of top level async/await functions introduces more learning pain to newcomers and anyone who's still got a callback based codebase is probably experienced enough to wade through "async/await first" documentation at this point.

@vitaly-t
Copy link
Contributor

vitaly-t commented Nov 22, 2022

Just so, I dropped NodeJS v8.0.0 support within pg-promise just 5 days ago, but I moved it up to 12.0.0, skipping 10.0.0.

Version 12.0.0 was released in May 2019, about 3.5 years ago. Time flies.

Thought you'd want to know, since it is still one of the biggest dependencies out there for this library.

b.t.w. I run checks inside the default loader - ./index.js.

@brianc
Copy link
Owner Author

brianc commented Nov 22, 2022

That's good to know! Thank you @vitaly-t

@vitaly-t

This comment was marked as off-topic.

@abenhamdine
Copy link
Contributor

These days, many nodejs modules are dropping suport for node <12 or even node <14 so it's seems very reasonable to drop support for node <10

@sehrope
Copy link
Contributor

sehrope commented Dec 21, 2022

I suggest sticking with the supported versions of the nodejs release schedule itself: https://github.com/nodejs/release#release-schedule

If the node version is not receiving maintenance updates then it's reasonable to withdraw module support. It's not exactly a short time period either as LTS releases are supported for 3+ years. People that don't upgrade their node versions are not likely to update their dependencies either. There aren't significant issues upgrading node versions either as core does a fantastic job at maintaining backwards compatability.

While it's helpful to support as many older versions as possible, not having a well defined expiration becomes a drag over time as there's no well defined cut-off for when to end support. We see this in the PGJDBC driver where we're still pushing security fixes for ancient versions of the JDK. Testing those versions becomes a pain as well as the CI platforms themselves withdraw support.

If anything, have the official policy be whatever is supported by nodejs itself, best effort for anything older, and keep the CI / build platform inching the modern supported versions as the need arises. So if the older versions are causing issues with the CI, bump it up to 10.x, 12.x or 14.x. If you are adding new code and it'd be simpler / faster / smarter to use something available only in a newer version, then go for it and bump the CI matrix.

@danthegoodman
Copy link

I'd like to see this happen too, as I've noticed some downstream dependencies of pg are bumping up their minimum supported version. For example, pg-types is up to v4, which appears to include some performance improvement commits as well. I like improved performance.

Would you prefer to see a small v9 release where the only breaking change is the node version change and a few dependency bumps, or are there additional things that you think are worth putting in a new major release?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants