You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Make next release semver-major/Request for 2.x release with backports #646
@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 😬
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.
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.
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.
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 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.
@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
Hi everybody,
like we discussed in the last N-API meeting (June 29th 2020) tomorrow I will provide to merge the following PR #723 and then create and publish a new release 2.0.2.
Activity
NickNaso commentedon Jan 10, 2020
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 commentedon Jan 10, 2020
Makes sense to me.
mhdawson commentedon Jan 13, 2020
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 commentedon Jan 18, 2020
Would like #594 and #653 to be addressed before we can make next semver-major release since they are likely to introduce breaking changes.
blagoev commentedon Mar 16, 2020
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 commentedon Mar 19, 2020
@gabrielschulhof, @NickNaso We should probably add that to the agenda for the next N-API team meeting.
addaleax commentedon Apr 22, 2020
Bump? It’s been 5 months since the last release…
Peg node-addon-api version to unreleased branch
legendecas commentedon Apr 23, 2020
@addaleax We are waiting on the checklist here #689 to be all closed.
addaleax commentedon Apr 23, 2020
@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 😬
blagoev commentedon Apr 23, 2020
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 commentedon Apr 23, 2020
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 commentedon Apr 23, 2020
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 commentedon Apr 24, 2020
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.
12 remaining items
mhdawson commentedon Apr 30, 2020
@addaleax do you have a list of which specific ones are non-breaking and that you think would be important to backport?
mhdawson commentedon Apr 30, 2020
@addaleax more generally though a conversation might be good around EOL Node.js LTS versions factoring these in:
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 commentedon Apr 30, 2020
@mhdawson The one I am personally concerned about is 4e88506, but others might have other commits they were waiting for.
addaleax commentedon Apr 30, 2020
@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 commentedon Apr 30, 2020
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 commentedon Apr 30, 2020
Going to re-open so that we don't miss closing out on the request for a 2.x release.
[-]Make next release semver-major[/-][+]Make next release semver-major/Request for 2.x release with backports[/+]gabrielschulhof commentedon May 11, 2020
@addaleax to backport 4e88506 we also need to backport 86384f9 and we should also backport the subsequent 7f56a78 which fixes #660.
#723
gabrielschulhof commentedon May 18, 2020
Maybe we should check master against 10.15.2 as well.
NickNaso commentedon Jun 30, 2020
Hi everybody,
like we discussed in the last N-API meeting (June 29th 2020) tomorrow I will provide to merge the following PR #723 and then create and publish a new release 2.0.2.
NickNaso commentedon Jul 1, 2020
I'm closing the issue because I just provided to publish the release 2.0.2.