-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
APIs removed in V8 7.0 and native addons #23122
Comments
wasn't our big plan always to shim 68 and 69 for 10.x and them push 70 to 11.x? |
@devsnek this issue is about 11.x |
/cc @nodejs/v8-update |
What if we float a patch that changes that? Doesn't break ABI but should result in a flurry of bug reports against add-ons that need upgrading.
If 2018-10-23 is still the target date then I agree. Floating shims for a release cycle doesn't trouble me. |
The V8 commit in question is v8/v8@5acf205, btw. I don’t know if there are others that are relevant.
That seems like a good idea. Looking into it, it’s doable but it’s not trivial because some of the replacement APIs don’t even exist in Node 10. |
BTW: 7.0 is not stable yet, we could petition for reverting of v8/v8@5acf205. |
@nodejs/v8 ^^^ |
I just took a look. It seems the change in question is a mix of removing APIs that are marked @danelphick has offered to partially revert this change to address the latter. I.e. instead of removing, we would move them to V8_DEPRECATED. We will still remove APIs that were already marked V8_DEPRECATED though. However, the underlying issue here is that V8 version bumps happen a lot more often than Node.js. If V8 was to accommodate to Node.js' deprecation policy, we would need a whole year to remove an API. We did that previously with the legacy debugging protocol, but I don't think this is something we can do in general. I think we need an actual discussion on this underlying issue, going forward. The motivation behind this particular change is to share objects between isolates in order to save memory. That means that where we derived the isolate from the object via |
@hashseed Some of the APIs just used
That sounds exciting :) |
I think in this particular change it's possible to shim the removed API with a floating patch. However, this may not solve similar issues in the future. |
Would it be possible to restate Node.js' deprecation policy towards native modules to exclude V8's API? Rationale:
|
We have some text in the collaborator guide: https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md#breaking-changes-and-deprecations
|
I don’t think that’s realistic for frequently-used APIs like some of the ones being removed here… a lot of legacy native addons do not receive much maintenance, and so having a deprecation warning for at least a full Node.js cycle would be ideal… |
what if we just float a patch for keeping 11.x unbroken and change our policy and break in 12.x |
This is the diff of https://gist.github.com/targos/efd41838f402e78c4caa96d4d18168de |
As Yang stated above, we're going to put back all the V8_DEPRECATE_SOON methods that were deleted in that change (but instead mark them V8_DEPRECATED). As such I've uploaded https://chromium-review.googlesource.com/c/v8/v8/+/1251422. |
I brought up the request to revert, just as a way to buy a little time (that will allow for a smoother release of node11 with V8 7.0). I'd would like to compliment @targos for the initiative to land 7.0 in |
Most (if not all) of the failures I see in CitGM include NAN. Shouldn't https://github.com/nodejs/nan/ be updated instead of changing anything here? |
This is the list of failed compilation I got from the above CITGM run on ubuntu16
It also seems to me that most (if not all) fail via nodejs/nan |
With respect to N-API being an alternative for the modules, we're tracking evaluating the impacted modules in nodejs/abi-stable-node#346 - the intention is to evaluate if these are good candidates to move to N-API, and if so, engage with module authors on starting a port. However, N-API adoption is slow so we'll probably have to deal with issues like this for the near term. |
First step nodejs/nan#808 |
Should we consider this resolved, or do people feel that we need to have a larger discussion around our management of V8 API deprecations/changes somewhere? |
IHMO if we turn on |
@refack I guess you can feel free to open a PR with that? |
Refs: v8/v8@7.0.276.22...7.0.276.24 PR-URL: #23158 Refs: #23122 Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>
Reverting this enables us to provide slower, but longer-lasting replacements for the deprecated APIs. Original commit message: Put back deleted V8_DEPRECATE_SOON methods This partially reverts https://chromium-review.googlesource.com/c/v8/v8/+/1177861, which deleted many V8_DEPRECATE_SOON methods rather than moving them to V8_DEPRECATED first. This puts them back and marks them V8_DEPRECATED. Note V8_DEPRECATED that were deleted in the same CL stay deleted. NOTRY=true NOPRESUBMIT=true NOTREECHECKS=true Bug: v8:7786, v8:8240 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I00330036d957f98dab403465b25e30d8382aac22 Reviewed-on: https://chromium-review.googlesource.com/1251422 Commit-Queue: Dan Elphick <[email protected]> Reviewed-by: Yang Guo <[email protected]> Reviewed-by: Michael Hablich <[email protected]> Cr-Commit-Position: refs/branch-heads/7.0@{#49} Cr-Branched-From: 6e2adae6f7f8e891cfd01f3280482b20590427a6-refs/heads/7.0.276@{#1} Cr-Branched-From: bc08a8624cbbea7a2d30071472bc73ad9544eadf-refs/heads/master@{#55424} Refs: v8/v8@9136dd8 Refs: #23122 PR-URL: #23158 Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>
Add back a number deprecated APIs, using shims that should work well enough at least for the duration of Node 11 and do not come with significant maintenance overhead. Refs: #23122 PR-URL: #23158 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>
@addaleax ... what is the status on this? |
@jasnell I think we’re good as far as the situation around v10.x/v11.x is concerned… the rest here is more about future-proofing |
Ok, taking it off the 11.0.0 milestone then |
* `V8_DEPRECATION_WARNINGS` is here for explicity. It is already defined in `node.gypi`, and `addon.gypi`. * `V8_IMMINENT_DEPRECATION_WARNINGS` added to warn addons authors. * `OPENSSL_THREADS` apears in the openSSL `.h` files, and was only defined via GYP for the node build. PR-URL: nodejs#23426 Fixes: nodejs#23167 Refs: nodejs#23122 Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
Should this remain open? If so, is there anything specific that is actionable at this time? |
We added #23426 which adds warnings for APIs that are |
Add back a number deprecated APIs, using shims that should work well enough at least for the duration of Node 11 and do not come with significant maintenance overhead. Refs: nodejs/node#23122 PR-URL: nodejs/node#23158 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Patch-Filename: deps_provide_more_v8_backwards_compatibility.patch
Add back a number deprecated APIs, using shims that should work well enough at least for the duration of Node 11 and do not come with significant maintenance overhead. Refs: nodejs/node#23122 PR-URL: nodejs/node#23158 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Patch-Filename: deps_provide_more_v8_backwards_compatibility.patch
Add back a number deprecated APIs, using shims that should work well enough at least for the duration of Node 11 and do not come with significant maintenance overhead. Refs: nodejs/node#23122 PR-URL: nodejs/node#23158 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Patch-Filename: deps_provide_more_v8_backwards_compatibility.patch
There was no activity for over a year and we are now at V8 8.0. I guess this is resolved and I am closing this. Please reopen in case there is more left to do. |
Several API calls from V8 were deprecated in version 7.0 (that ships w/ node 12), this commit replaces then Refs: nodejs/node#23122 nodejs/node#23159 bcoin-org/bcrypto#7
Several API calls from V8 were deprecated in version 7.0 (that ships w/ node 12), this commit replaces then Refs: nodejs/node#23122 nodejs/node#23159 bcoin-org/bcrypto#7
Several API calls from V8 were deprecated in version 7.0 (that ships w/ node 12), this commit replaces then Refs: nodejs/node#23122 nodejs/node#23159 bcoin-org/bcrypto#7
Several API calls from V8 were deprecated in version 7.0 (that ships w/ node 12), this commit replaces then Refs: nodejs/node#23122 nodejs/node#23159 bcoin-org/bcrypto#7
Currently, CITGM failures are dominated by addons failing because of APIs that were removed in V8 7.0 (Example run).
Most of the removed functions are simple wrappers that take now-required arguments from other sources, for example, the now-removed
value->ToString()
was essentially just a shorthand forvalue->ToString(Isolate::GetCurrent()->GetCurrentContext()).FromMaybe(Local<String>())
.Most of these APIs (all widely used ones, at least) do currently not print deprecation warnings when building with Node 10.
So, the question is: What, if anything, do we do about this?
We have the option of maintaining the deprecated APIs ourselves for a while, but I’m not sure how people feel about that.
We can also do ecosystem outreach on our own, but I highly doubt that that is going to restore CITGM results in time for Node 11, and given the large number of addons that are affected by this, we definitely can’t address all cases where this is an issue by ourselves.
The text was updated successfully, but these errors were encountered: