Node-addon-api: Make next release semver-major/Request for 2.x release with backports

[gabrielschulhof]

@addaleax pointed out that because of the removal of support for v6.x and v8.x the next release must be semver-major.

[NickNaso]

Hi @gabrielschulhof ,
I agree with you we can discuss about it at next N-API meeting and then proceed to make the release 3.0.0.

[mhdawson]

Makes sense to me.

[mhdawson]

Discussed in the N-API team meeting today. We can wait until we have enough to do a release, and then we'll make it SemVer major at that point.

[legendecas]

Would like https://github.com/nodejs/node-addon-api/issues/594 and https://github.com/nodejs/node-addon-api/issues/653 to be addressed before we can make next semver-major release since they are likely to introduce breaking changes.

[blagoev]

when will be the next version released? There are a lot of critical fixes committed in master and pending release. Like memory leaks and crashes.

[mhdawson]

@gabrielschulhof, @NickNaso We should probably add that to the agenda for the next N-API team meeting.

[addaleax]

Bump? It’s been 5 months since the last release…

[legendecas]

@addaleax We are waiting on the checklist here https://github.com/nodejs/node-addon-api/issues/689 to be all closed.

[addaleax]

@legendecas That’s understandable, but… holding up releases like that is not great in terms of DX and kind of makes me want to start maintaining a fork of this repo that actively releases :grimacing:

[blagoev]

We have done a release based of a fork. IMO critical fixes and memory leaks should not wait for other features too much. Still it is what it is, and we are waiting for node-addon-api v3 to do a proper release.

[addaleax]

Right, I feel like we should at least have another v2.x release here. Mixing in a breaking change with critical fixes doesn’t seem like a great choice.

[blagoev]

Well on this one the fixes required breaking changes. My comment was about the new features that are planned and still holding up the release, but I think the team knows better.

[mhdawson]

I'll add that the team was not aware that people were actively waiting for a new release, but also agree it was probably longer since the last release than it should be have been.

@nodejs/addon-api any concerns with doing a release with what is currently landed as a 2.x release and then following that up with the planned 3.0.0 release when it is ready? If not @NickNaso do you have time to do the release next week? Otherwise I can take a look at doing it.

[addaleax]

@mhdawson I think it’s a safe default assumption that anybody who opens a PR has the goal of using it in a release soon afterwards.

[blagoev]

The next release should be a major version since it has breaking changes.

[mhdawson]

@blagoev I guess I did not think it though enough and based my suggestion on @addaleax's suggestion that we have another v2.x release. Which was "one the fixes required breaking changes"? To my recollection we were very conservative on what was marked breaking (ie we did not believe any of the changes would affect any real code) so we should look carefully at the change if there is a strong need for a v2.x release versus the planned major release. The major motivation for a major was to specifically drop support for Node.js 6.x (EDIT should have said 6.x and 8.x).

If we can agree on what is most useful we can see if we can expedite a release of that next week now that we understand the lack of a release is causing problems.

[blagoev]

I think its node 8 support that's dropped as well. But if you ask me that's breaking change and should be released as a major version.
We are indeed waiting for the next version since we are using a fork right now. But that's not good reason to break semver. If you can expedite the next major version and leave some of the listed features for the next version after it it would be great.

cheers

[mhdawson]

@blagoev thanks for letting us know what makes the most sense for you.

@nodejs/n-api revised proposal:

expediting:

• find places were we document which versions of Node.js are support and remove all lower than
  10.x

Then doing a release, and leave

• src: add support for addon instance data 663
• src: change guards to NAPI_VERSION > 5 697 - (3 approvals)

to a later release if they are not ready? If so @NickNaso do you have time to do the release next week? Otherwise I can take a look at doing it.

[NickNaso]

Hi @mhdawson,
yes, I can work to make the next release next week.

[mhdawson]

@NickNaso thanks! Let me know if you need anything from me.

[NickNaso]

I'm starting to make the new release. If I will not have problem with CI it will go out very soon.

[NickNaso]

I'm closing the issue because the new version of node-addon-api has been released.

[addaleax]

@NickNaso @mhdawson Any plans to release another v2.x? That might be relevant for people who can’t just drop support for older Node.js versions while also wanting bugfixes.

[mhdawson]

@addaleax do you have a list of which specific ones are non-breaking and that you think would be important to backport?

[mhdawson]

@addaleax more generally though a conversation might be good around EOL Node.js LTS versions factoring these in:

• I don't think we had plans to support EOL version of Node.js
• For the most part (I know there are some other changes we tagged as SemVer major, but because we were being very very conservative) we only bumped the major to drop support for the EOL versions. So for use with non-EOL Node.js versions there is no reason not to use the current major.

Given that it seems strange to backport changes to a line that would only be used for EOL Node.js versions, and that we only really moved up from to discontinue support for...

I understand its a bit more grey than that, but I'm struggling with "you need to bump the major to drop support" and "you need to backport changes to the previous line to support the versions you dropped support for", which is only really necessary because "we bumped the major to drop support".

Ideally we would not have to force those using non-EOL Node versions to take a major just so that we can drop support for EOL versions.

[addaleax]

@mhdawson The one I am personally concerned about is https://github.com/nodejs/node-addon-api/commit/4e885069f1721dec1705c898383625dd2907f9e6, but others might have other commits they were waiting for.

[addaleax]

@mhdawson I get that, but semver-major releases that drop Node.js support propagate very slowly through the ecosystem, because it forces a semver-major release on all of its recursive dependents as well

[mhdawson]

If anybody has any others they think are important, please add to this issue and we will review/discuss a 2.x release which includes those.

[mhdawson]

Going to re-open so that we don't miss closing out on the request for a 2.x release.

[gabrielschulhof]

@addaleax to backport 4e88506 we also need to backport 86384f9 and we should also backport the subsequent 7f56a78 which fixes #660.

https://github.com/nodejs/node-addon-api/pull/723

[gabrielschulhof]

Maybe we should check master against 10.15.2 as well.

[NickNaso]

Hi everybody,
like we discussed in the last N-API meeting (June 29th 2020) tomorrow I will provide to merge the following PR https://github.com/nodejs/node-addon-api/pull/723 and then create and publish a new release 2.0.2.

[NickNaso]

I'm closing the issue because I just provided to publish the release 2.0.2.