drop --napi-modules earlier than dropping the "experimental" status #9
Comments
|
+1, and I don’t think there are any rules saying we need CTC approval. A regular PR that gets approved without significant opposition should be fine. |
|
I'm +1 to this. The only issue is that it makes it a bit trickier to emit the experimental feature warning which is currently gated by the flag. |
|
+1 from me |
|
Could we not add the experimental warning in |
|
not sure why this repository was chosen to open the issue, but we should probably ping @nodejs/n-api since it’s not one of the ones usually used for N-API discussions |
|
@evanlucas yes if I agree that this repo is an odd choice for this issue. I think it should be moved to the core repo because a lot of people might have opinions about this. |
|
I'm -1, as far as anyone can tell landing an unflagged feature means we are stuck with it for a very significant amount of time. How would this prove validity? |
|
I'd agree we should move this to the core node repo. |
|
@mhdawson can you please articulate why we need this? You did it way better than what I could do at the summit. |
|
We agreed on dropping |
"experimental" is our get-out-of-jail card here, we can do what we want with it at any time, caveat emptor. The flag is just an additional step above labelling it experimental. My memory of the VM Summit was that those involved in developing N-API were pretty strong on their desire to unflag this in order to get broad enough deployment to make the next phase of testing practical, otherwise they are stuck in a backwater twiddling their fingers (paraphrasing here!). As @mcollina said though, it'd be good to have a clearer explanation of the justification that was formed at that meeting in response to the push-back. @Fishrock123 has concerns and he may be persuaded by the same arguments that I was. I'm +1 on unflagging |
|
Some more points: a. If we are going to do this, we should try very hard not break the ABI compat. It's part of the testing, can we provide an ABI-stable node? We can argue that we should lift the "experimental" warning. To do so this feature needs users, and people that will start porting modules. N-API has a chicken and egg problem, it needs validation, however no one will put in the effort to migrate unless we graduate it to something "a bit more stable" sooner later than later. Removing the flag but keeping the warning is an intermediate step that we could do right now. |
|
The key issue is that until N-API is "real" it is hard for module owners (who we all know are busy) to justify the time doing a port. Until its "real" we'll probably be limited to a smallish set of module owners who we can convince to do a port for the benefit of the overall ecosystem The challenge is to balance getting enough feedback/use of the new API to be comfortable that it is ready to become non-experimental without stalling the overall effort by waiting too long. The discussion at the vm summit was that removing the flag was a step towards making it easier to consume (and a bit more "real"). Leaving in the warning (which would be emitted only if the user uses an N-API module) means consumers are still warned that they are using an experimental feature, without having to modify their deployment infrastructure to add an additional flag which can sometimes be difficult. The goal is still to get it to be non-experimental "soon" (ideally before 8 goes LTS), but removing the command line option is a concrete step we can do now. |
|
+1 to it not being "real" until the flag is removed... We can't expect
people to be taking it through the paces if their downstream cannot use the
feature without a flag
I have similar thoughts regarding http2, but I'll save that for another
thread 😇
…On Aug 17, 2017 10:41 AM, "Michael Dawson" ***@***.***> wrote:
The key issue is that until N-API is "real" it is hard for module owners
(who we all know are busy) to justify the time doing a port. Until its
"real" we'll probably be limited to a smallish set of module owners who we
can convince to do a port for the benefit of the overall ecosystem
The challenge is to balance getting enough feedback/use of the new API to
be comfortable that it is ready to become non-experimental without stalling
the overall effort by waiting too long.
The discussion at the vm summit was that removing the flag was a step
towards making it easier to consume (and a bit more "real"). Leaving in the
warning (which would be emitted only if the user uses an N-API module)
means consumers are still warned that they are using an experimental
feature, without having to modify their deployment infrastructure to add an
additional flag which can sometimes be difficult.
The goal is still to get it to be non-experimental "soon" (ideally before
8 goes LTS), but removing the command line option is a concrete step we can
do now.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#9 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAecVwyvw7FuysX77OK4pXdQJGMA79Q_ks5sZHtOgaJpZM4Opf3K>
.
|
|
Was discussed in this weeks CTC/TSC meeting please see this comment: nodejs/node#14902 (comment). Closing as I think any further discussion can be handle PR #14902. |
Remove the command line flag that was needed for N-API module loading. Re: nodejs/vm#9
Remove the command line flag that was needed for N-API module loading. Re: nodejs/vm#9 PR-URL: #14902 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Hitesh Kanwathirtha <[email protected]>
Remove the command line flag that was needed for N-API module loading. Re: nodejs/vm#9 PR-URL: #14902 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Hitesh Kanwathirtha <[email protected]>
Remove the command line flag that was needed for N-API module loading. Re: nodejs/vm#9 PR-URL: nodejs/node#14902 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Hitesh Kanwathirtha <[email protected]>
Remove the command line flag that was needed for N-API module loading. Re: nodejs/vm#9 PR-URL: nodejs/node#14902 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Hitesh Kanwathirtha <[email protected]>
Remove the command line flag that was needed for N-API module loading. Re: nodejs/vm#9 PR-URL: nodejs#14902 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Hitesh Kanwathirtha <[email protected]>
Remove the command line flag that was needed for N-API module loading. Re: nodejs/vm#9 Backport-PR-URL: #19447 PR-URL: #14902 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Hitesh Kanwathirtha <[email protected]>
In order to prove the validity, I propose we should just drop the
--napi-modulesflag and keep the experimental status.I'm not sure we need @nodejs/ctc approval for this, but I'll add it to the agenda anyway.
The text was updated successfully, but these errors were encountered: