-
Notifications
You must be signed in to change notification settings - Fork 592
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
Dropping 0.12 Support #1855
Comments
Maintenance for 0.12 officially ends at the end of this year per the LTS schedule. |
cc: @ofrobots too |
I can't wait until 0.12 goes EOL as well. I do suspect that many people will continue using 0.12 for a little bit after it goes out of support. Looking at the metrics from npm, 0.10 still has some usage even though there is no official support for it by Node.js core:
It would have been nice if we could get download stats from npm which correlate the downloads of When it comes to dropping support for 0.12 is concerned, there are a few types of actions we could take:
Continuing to state that we support 0.12 after Node.js core (and OpenSSL) drops support for it would be irresponsible, so we should 'drop support'. However, we do know that some folks will continue using the client libraries with 0.12 for a little while longer (at their own risk). Forcibly breaking these users by eagerly jumping on new language features would be unfortunate. We should give users some time to migrate. I think we should balance the trade-off here. IMHO, we should modify the This would be a lot easier to decide if we has detailed npm download stats. Thoughts? |
npm would be happy to provide Google Cloud with stats on which versions of node we see making requests to the registry. We'd need the list of IPs (or IP ranges) google cloud machines are using. |
@seldo it is possible to to know the node version distribution for a given package regardless of the ip address? |
Absolutely. |
@seldo Great! in that case the stats on the module google-auth-library would probably give us the data we need. |
Here's the data since the 1st of January, since that happened to be easy to run: https://docs.google.com/spreadsheets/d/1VxzjALwzO_McvTyzEN-PCR_tDx9Y-vRKLn8Qi358yzM/edit?usp=sharing TLDR: I personally do not think that it's a good idea to abandon support for 4.6% of your userbase, but then that's a problem I have with Node as well :-) |
@seldo many thanks! |
Quick update. According to #1994 (comment) gRPC has dropped 0.12 support. grpc/grpc#8895 confirmed that. I created grpc/grpc#9707 to cleanup the remaining references to Node.js 0.12 in gRPC. |
We've changed our minimum supported version in the |
Opening this back up.
If we want to be able to do this anytime soon on these libraries, we really need to do it now. I assert that we should. We have already ceased testing on Node 0.12. |
@seldo Would it be possible to get updated numbers? |
Note: I am about to send a PR that does this (along with the beta/GA stuff), but I still consider this to be an open discussion. That said, we will almost certainly do it if nobody dissents, and right now the general consensus seems to be to do it. |
I have updated the spreadsheet. TLDR: 7 15% So 0.x people are still 4.1%. Source is 86k requests over the last 7 days. |
Thank you so much @seldo. We did decide to bump I assume based on the Node 0.10 traffic that it will still install on Node 0.12 (presumably with some kind of warning), but officially we are moving to 4.0.0+. Thank you so much! |
Good choice! I don't think that there is any good reason to support v0.1x. Glad to see the move to 4.x+! |
request
is a very core module to our project and they dropped 0.12 support about a month ago. It would be unfortunate to lock down to a single release, because they commonly receive security updates, and they are at the wheel of every [non-gRPC] API request that we send.The most recent version of
request
that is compatible with Node v0.12 is2.76.0
. Our dependency,google-auto-auth
, is depending on2.79.0
. By default,npm
will still install it after printing a warning:... but it doesn't mean it will work at runtime.
Additionally, there are about 3 other dependencies we use which are no longer supporting Node versions < 4. Is it time we join the others and support Node runtimes >= 4?
// @omaray @jgeewax @jmdobry @JustinBeckwith
// (please CC others who might be interested)
The text was updated successfully, but these errors were encountered: