chore: release 9.4.1

[github-actions]

🤖 I have created a release *beep* *boop*

9.4.1 (2023-10-27)

Bug Fixes

• create Python symlink only during builds, and clean it up after (#2721) (0f1f667)

Core

• find python checks order changed on windows (#2872) (b030555)

Tests

• increase mocha timeout (#2887) (445c28f)
• update expired certs (#2908) (5746691)

Doc

• Add note about Python symlinks (PR 2362) to CHANGELOG.md for 9.1.0 (#2783) (b3d41ae)
• README.md Do not hardcode the supported versions of Python (#2880) (bb93b94)
• Update windows installation instructions in README.md (#2882) (c9caa2e)

---

This PR was generated with Release Please. See documentation.

[lukekarrys]

This shouldn't be released in it's current state. #2770 landed with a breaking change but isn't formatted like a conventional commit, so it didn't trigger this PR to be 10.0.0 as it should be.

[legobeat]

@lukekarrys Do you think we can consider #2849 for inclusion into a 9.4.1? Given that #2796 got included in 9.4.0 and is actually breaking Node 12.x support (#2873).

Then a more long-term solution which doesn't need to consider 12.x support can be targeting a 10.x release.

[Trott]

If someone does git commit --allow-empty -m "chore: release 10.0.0" -m "Release-As: 10.0.0" and pushes that to the main branch, I think Release Please will either update this PR or open a new one to release this stuff as 10.0.0. I think.....

[mfranzs]

Hi - is there any documentation on release processes here / when we can hope the latest main will be released? There are some critical fixes breaking Electron builds that we're waiting for. Thank you for this package!

[lukekarrys]

There is not any current documentation @mfranzs. But my goal is to release the latest main branch this week. Although I should note that it will likely be release as a new major version 10.0.0.

[mfranzs]

Thank you very much!

[legobeat]

@lukekarrys any chance we can actually get a 9.x release? LMK if you see any blockers or other things you would need assistance with to make that happen.

^9.x is still dependended on by various unmaintained widely used ecosystem packages..

[DeeDeeG]

Stuff to consider doing before releasing?

EDIT: Besides @legobeat's point above (which I don't want to bury with my comment so shortly after)... Might want to resolve concerns mentioned in #2857 (comment) before releasing?

This bit:

Seems like the check [OP linked to in their comment] should be !=, not <. Otherwise changes requiring bumping installVersion have to be backwards-compatible due to the aforementioned scenario, which doesn't seem reasonable. If the installVersion do not match it seems reasonable to force a reinstall.

Would be good not to impose backward-compatibility guarantees on any stuff that depends on a particular installVersion matching, I think? And it's a ~3 character diff to fix it. I can do a PR going off of that person's comment if wanted. (Or the folks from that PR might have input if they were pinged, I guess.)

---

How to release / How to set the semver for the release

And (at least for stuff that happens on GitHub) the release process is basically https://github.com/google-github-actions/release-please-action#readme --> https://github.com/googleapis/release-please#readme. (And after that, I'm sure some maintainer(s) here know about how publishing the new version to the npm package registry works.)

You can manually set the version number (like 9.4.1 or 10.0.0) for release-please to follow by adding a commit with Release-As: x.x.x in the body of the commit message (below the first line)
https://github.com/googleapis/release-please#how-do-i-change-the-version-number

I did the PR to add release-please to this repo at the request of multiple active node-gyp contributors at the time, so if I can be of help by answering questions why it was set up any particular way I am happy to do so, but it was set up kind of arbitrarily just to make releases more automated than the existing process, to put it in a nutshell.

[lukekarrys]

I'm going to close this release PR so that when #2917 lands in release/v9, the new release-please action for that branch will create this v9.4.1 PR. And then I will push a new commit (as mentioned above #2878 (comment)) to create a v10.0.0 PR.

We can also use the new v10.0.0 PR to discuss any other changes that should land before the semver major is released.

[github-actions]

🤖 I have created a release *beep* *boop*

9.4.1 (2023-10-27)

Bug Fixes

• create Python symlink only during builds, and clean it up after (#2721) (0f1f667)

Core

• find python checks order changed on windows (#2872) (b030555)

Tests

• increase mocha timeout (#2887) (445c28f)
• update expired certs (#2908) (5746691)

Doc

• Add note about Python symlinks (PR 2362) to CHANGELOG.md for 9.1.0 (#2783) (b3d41ae)
• README.md Do not hardcode the supported versions of Python (#2880) (bb93b94)
• Update windows installation instructions in README.md (#2882) (c9caa2e)

---

This PR was generated with Release Please. See documentation.

[lukekarrys]

This shouldn't be released in it's current state. #2770 landed with a breaking change but isn't formatted like a conventional commit, so it didn't trigger this PR to be 10.0.0 as it should be.

[legobeat]

@lukekarrys Do you think we can consider #2849 for inclusion into a 9.4.1? Given that #2796 got included in 9.4.0 and is actually breaking Node 12.x support (#2873).

Then a more long-term solution which doesn't need to consider 12.x support can be targeting a 10.x release.

[Trott]

If someone does git commit --allow-empty -m "chore: release 10.0.0" -m "Release-As: 10.0.0" and pushes that to the main branch, I think Release Please will either update this PR or open a new one to release this stuff as 10.0.0. I think.....

[mfranzs]

Hi - is there any documentation on release processes here / when we can hope the latest main will be released? There are some critical fixes breaking Electron builds that we're waiting for. Thank you for this package!

[lukekarrys]

There is not any current documentation @mfranzs. But my goal is to release the latest main branch this week. Although I should note that it will likely be release as a new major version 10.0.0.

[mfranzs]

Thank you very much!

[legobeat]

@lukekarrys any chance we can actually get a 9.x release? LMK if you see any blockers or other things you would need assistance with to make that happen.

^9.x is still dependended on by various unmaintained widely used ecosystem packages..

[DeeDeeG]

Stuff to consider doing before releasing?

EDIT: Besides @legobeat's point above (which I don't want to bury with my comment so shortly after)... Might want to resolve concerns mentioned in #2857 (comment) before releasing?

This bit:

Seems like the check [OP linked to in their comment] should be !=, not <. Otherwise changes requiring bumping installVersion have to be backwards-compatible due to the aforementioned scenario, which doesn't seem reasonable. If the installVersion do not match it seems reasonable to force a reinstall.

Would be good not to impose backward-compatibility guarantees on any stuff that depends on a particular installVersion matching, I think? And it's a ~3 character diff to fix it. I can do a PR going off of that person's comment if wanted. (Or the folks from that PR might have input if they were pinged, I guess.)

---

How to release / How to set the semver for the release

And (at least for stuff that happens on GitHub) the release process is basically https://github.com/google-github-actions/release-please-action#readme --> https://github.com/googleapis/release-please#readme. (And after that, I'm sure some maintainer(s) here know about how publishing the new version to the npm package registry works.)

You can manually set the version number (like 9.4.1 or 10.0.0) for release-please to follow by adding a commit with Release-As: x.x.x in the body of the commit message (below the first line)
https://github.com/googleapis/release-please#how-do-i-change-the-version-number

I did the PR to add release-please to this repo at the request of multiple active node-gyp contributors at the time, so if I can be of help by answering questions why it was set up any particular way I am happy to do so, but it was set up kind of arbitrarily just to make releases more automated than the existing process, to put it in a nutshell.

[lukekarrys]

I'm going to close this release PR so that when #2917 lands in release/v9, the new release-please action for that branch will create this v9.4.1 PR. And then I will push a new commit (as mentioned above #2878 (comment)) to create a v10.0.0 PR.

We can also use the new v10.0.0 PR to discuss any other changes that should land before the semver major is released.

[github-actions]

🤖 I have created a release *beep* *boop*

9.4.1 (2023-10-27)

Bug Fixes

• create Python symlink only during builds, and clean it up after (#2721) (0f1f667)

Core

• find python checks order changed on windows (#2872) (b030555)

Tests

• increase mocha timeout (#2887) (445c28f)
• update expired certs (#2908) (5746691)

Doc

• Add note about Python symlinks (PR 2362) to CHANGELOG.md for 9.1.0 (#2783) (b3d41ae)
• README.md Do not hardcode the supported versions of Python (#2880) (bb93b94)
• Update windows installation instructions in README.md (#2882) (c9caa2e)

---

This PR was generated with Release Please. See documentation.

[lukekarrys]

This shouldn't be released in it's current state. #2770 landed with a breaking change but isn't formatted like a conventional commit, so it didn't trigger this PR to be 10.0.0 as it should be.

[legobeat]

@lukekarrys Do you think we can consider #2849 for inclusion into a 9.4.1? Given that #2796 got included in 9.4.0 and is actually breaking Node 12.x support (#2873).

Then a more long-term solution which doesn't need to consider 12.x support can be targeting a 10.x release.

[Trott]

If someone does git commit --allow-empty -m "chore: release 10.0.0" -m "Release-As: 10.0.0" and pushes that to the main branch, I think Release Please will either update this PR or open a new one to release this stuff as 10.0.0. I think.....

[mfranzs]

Hi - is there any documentation on release processes here / when we can hope the latest main will be released? There are some critical fixes breaking Electron builds that we're waiting for. Thank you for this package!

[lukekarrys]

There is not any current documentation @mfranzs. But my goal is to release the latest main branch this week. Although I should note that it will likely be release as a new major version 10.0.0.

[mfranzs]

Thank you very much!

[legobeat]

@lukekarrys any chance we can actually get a 9.x release? LMK if you see any blockers or other things you would need assistance with to make that happen.

^9.x is still dependended on by various unmaintained widely used ecosystem packages..

[DeeDeeG]

Stuff to consider doing before releasing?

EDIT: Besides @legobeat's point above (which I don't want to bury with my comment so shortly after)... Might want to resolve concerns mentioned in #2857 (comment) before releasing?

This bit:

Seems like the check [OP linked to in their comment] should be !=, not <. Otherwise changes requiring bumping installVersion have to be backwards-compatible due to the aforementioned scenario, which doesn't seem reasonable. If the installVersion do not match it seems reasonable to force a reinstall.

Would be good not to impose backward-compatibility guarantees on any stuff that depends on a particular installVersion matching, I think? And it's a ~3 character diff to fix it. I can do a PR going off of that person's comment if wanted. (Or the folks from that PR might have input if they were pinged, I guess.)

---

How to release / How to set the semver for the release

And (at least for stuff that happens on GitHub) the release process is basically https://github.com/google-github-actions/release-please-action#readme --> https://github.com/googleapis/release-please#readme. (And after that, I'm sure some maintainer(s) here know about how publishing the new version to the npm package registry works.)

You can manually set the version number (like 9.4.1 or 10.0.0) for release-please to follow by adding a commit with Release-As: x.x.x in the body of the commit message (below the first line)
https://github.com/googleapis/release-please#how-do-i-change-the-version-number

I did the PR to add release-please to this repo at the request of multiple active node-gyp contributors at the time, so if I can be of help by answering questions why it was set up any particular way I am happy to do so, but it was set up kind of arbitrarily just to make releases more automated than the existing process, to put it in a nutshell.

[lukekarrys]

I'm going to close this release PR so that when #2917 lands in release/v9, the new release-please action for that branch will create this v9.4.1 PR. And then I will push a new commit (as mentioned above #2878 (comment)) to create a v10.0.0 PR.

We can also use the new v10.0.0 PR to discuss any other changes that should land before the semver major is released.

[github-actions]

🤖 I have created a release *beep* *boop*

9.4.1 (2023-10-27)

Bug Fixes

• create Python symlink only during builds, and clean it up after (#2721) (0f1f667)

Core

• find python checks order changed on windows (#2872) (b030555)

Tests

• increase mocha timeout (#2887) (445c28f)
• update expired certs (#2908) (5746691)

Doc

• Add note about Python symlinks (PR 2362) to CHANGELOG.md for 9.1.0 (#2783) (b3d41ae)
• README.md Do not hardcode the supported versions of Python (#2880) (bb93b94)
• Update windows installation instructions in README.md (#2882) (c9caa2e)

---

This PR was generated with Release Please. See documentation.

[lukekarrys]

This shouldn't be released in it's current state. #2770 landed with a breaking change but isn't formatted like a conventional commit, so it didn't trigger this PR to be 10.0.0 as it should be.

[legobeat]

@lukekarrys Do you think we can consider #2849 for inclusion into a 9.4.1? Given that #2796 got included in 9.4.0 and is actually breaking Node 12.x support (#2873).

Then a more long-term solution which doesn't need to consider 12.x support can be targeting a 10.x release.

[Trott]

If someone does git commit --allow-empty -m "chore: release 10.0.0" -m "Release-As: 10.0.0" and pushes that to the main branch, I think Release Please will either update this PR or open a new one to release this stuff as 10.0.0. I think.....

[mfranzs]

Hi - is there any documentation on release processes here / when we can hope the latest main will be released? There are some critical fixes breaking Electron builds that we're waiting for. Thank you for this package!

[lukekarrys]

There is not any current documentation @mfranzs. But my goal is to release the latest main branch this week. Although I should note that it will likely be release as a new major version 10.0.0.

[mfranzs]

Thank you very much!

[legobeat]

@lukekarrys any chance we can actually get a 9.x release? LMK if you see any blockers or other things you would need assistance with to make that happen.

^9.x is still dependended on by various unmaintained widely used ecosystem packages..

[DeeDeeG]

Stuff to consider doing before releasing?

EDIT: Besides @legobeat's point above (which I don't want to bury with my comment so shortly after)... Might want to resolve concerns mentioned in #2857 (comment) before releasing?

This bit:

Seems like the check [OP linked to in their comment] should be !=, not <. Otherwise changes requiring bumping installVersion have to be backwards-compatible due to the aforementioned scenario, which doesn't seem reasonable. If the installVersion do not match it seems reasonable to force a reinstall.

Would be good not to impose backward-compatibility guarantees on any stuff that depends on a particular installVersion matching, I think? And it's a ~3 character diff to fix it. I can do a PR going off of that person's comment if wanted. (Or the folks from that PR might have input if they were pinged, I guess.)

---

How to release / How to set the semver for the release

And (at least for stuff that happens on GitHub) the release process is basically https://github.com/google-github-actions/release-please-action#readme --> https://github.com/googleapis/release-please#readme. (And after that, I'm sure some maintainer(s) here know about how publishing the new version to the npm package registry works.)

You can manually set the version number (like 9.4.1 or 10.0.0) for release-please to follow by adding a commit with Release-As: x.x.x in the body of the commit message (below the first line)
https://github.com/googleapis/release-please#how-do-i-change-the-version-number

I did the PR to add release-please to this repo at the request of multiple active node-gyp contributors at the time, so if I can be of help by answering questions why it was set up any particular way I am happy to do so, but it was set up kind of arbitrarily just to make releases more automated than the existing process, to put it in a nutshell.

[lukekarrys]

I'm going to close this release PR so that when #2917 lands in release/v9, the new release-please action for that branch will create this v9.4.1 PR. And then I will push a new commit (as mentioned above #2878 (comment)) to create a v10.0.0 PR.

We can also use the new v10.0.0 PR to discuss any other changes that should land before the semver major is released.

[github-actions]

🤖 I have created a release *beep* *boop*

9.4.1 (2023-10-27)

Bug Fixes

• create Python symlink only during builds, and clean it up after (#2721) (0f1f667)

Core

• find python checks order changed on windows (#2872) (b030555)

Tests

• increase mocha timeout (#2887) (445c28f)
• update expired certs (#2908) (5746691)

Doc

• Add note about Python symlinks (PR 2362) to CHANGELOG.md for 9.1.0 (#2783) (b3d41ae)
• README.md Do not hardcode the supported versions of Python (#2880) (bb93b94)
• Update windows installation instructions in README.md (#2882) (c9caa2e)

---

This PR was generated with Release Please. See documentation.

[lukekarrys]

This shouldn't be released in it's current state. #2770 landed with a breaking change but isn't formatted like a conventional commit, so it didn't trigger this PR to be 10.0.0 as it should be.

[legobeat]

@lukekarrys Do you think we can consider #2849 for inclusion into a 9.4.1? Given that #2796 got included in 9.4.0 and is actually breaking Node 12.x support (#2873).

Then a more long-term solution which doesn't need to consider 12.x support can be targeting a 10.x release.

[Trott]

If someone does git commit --allow-empty -m "chore: release 10.0.0" -m "Release-As: 10.0.0" and pushes that to the main branch, I think Release Please will either update this PR or open a new one to release this stuff as 10.0.0. I think.....

[mfranzs]

Hi - is there any documentation on release processes here / when we can hope the latest main will be released? There are some critical fixes breaking Electron builds that we're waiting for. Thank you for this package!

[lukekarrys]

There is not any current documentation @mfranzs. But my goal is to release the latest main branch this week. Although I should note that it will likely be release as a new major version 10.0.0.

[mfranzs]

Thank you very much!

[legobeat]

@lukekarrys any chance we can actually get a 9.x release? LMK if you see any blockers or other things you would need assistance with to make that happen.

^9.x is still dependended on by various unmaintained widely used ecosystem packages..

[DeeDeeG]

Stuff to consider doing before releasing?

EDIT: Besides @legobeat's point above (which I don't want to bury with my comment so shortly after)... Might want to resolve concerns mentioned in #2857 (comment) before releasing?

This bit:

Seems like the check [OP linked to in their comment] should be !=, not <. Otherwise changes requiring bumping installVersion have to be backwards-compatible due to the aforementioned scenario, which doesn't seem reasonable. If the installVersion do not match it seems reasonable to force a reinstall.

Would be good not to impose backward-compatibility guarantees on any stuff that depends on a particular installVersion matching, I think? And it's a ~3 character diff to fix it. I can do a PR going off of that person's comment if wanted. (Or the folks from that PR might have input if they were pinged, I guess.)

---

How to release / How to set the semver for the release

And (at least for stuff that happens on GitHub) the release process is basically https://github.com/google-github-actions/release-please-action#readme --> https://github.com/googleapis/release-please#readme. (And after that, I'm sure some maintainer(s) here know about how publishing the new version to the npm package registry works.)

You can manually set the version number (like 9.4.1 or 10.0.0) for release-please to follow by adding a commit with Release-As: x.x.x in the body of the commit message (below the first line)
https://github.com/googleapis/release-please#how-do-i-change-the-version-number

I did the PR to add release-please to this repo at the request of multiple active node-gyp contributors at the time, so if I can be of help by answering questions why it was set up any particular way I am happy to do so, but it was set up kind of arbitrarily just to make releases more automated than the existing process, to put it in a nutshell.

[lukekarrys]

I'm going to close this release PR so that when #2917 lands in release/v9, the new release-please action for that branch will create this v9.4.1 PR. And then I will push a new commit (as mentioned above #2878 (comment)) to create a v10.0.0 PR.

We can also use the new v10.0.0 PR to discuss any other changes that should land before the semver major is released.

[github-actions]

🤖 I have created a release *beep* *boop*

9.4.1 (2023-10-27)

Bug Fixes

• create Python symlink only during builds, and clean it up after (#2721) (0f1f667)

Core

• find python checks order changed on windows (#2872) (b030555)

Tests

• increase mocha timeout (#2887) (445c28f)
• update expired certs (#2908) (5746691)

Doc

• Add note about Python symlinks (PR 2362) to CHANGELOG.md for 9.1.0 (#2783) (b3d41ae)
• README.md Do not hardcode the supported versions of Python (#2880) (bb93b94)
• Update windows installation instructions in README.md (#2882) (c9caa2e)

---

This PR was generated with Release Please. See documentation.

[lukekarrys]

This shouldn't be released in it's current state. #2770 landed with a breaking change but isn't formatted like a conventional commit, so it didn't trigger this PR to be 10.0.0 as it should be.

[legobeat]

@lukekarrys Do you think we can consider #2849 for inclusion into a 9.4.1? Given that #2796 got included in 9.4.0 and is actually breaking Node 12.x support (#2873).

Then a more long-term solution which doesn't need to consider 12.x support can be targeting a 10.x release.

[Trott]

If someone does git commit --allow-empty -m "chore: release 10.0.0" -m "Release-As: 10.0.0" and pushes that to the main branch, I think Release Please will either update this PR or open a new one to release this stuff as 10.0.0. I think.....

[mfranzs]

Hi - is there any documentation on release processes here / when we can hope the latest main will be released? There are some critical fixes breaking Electron builds that we're waiting for. Thank you for this package!

[lukekarrys]

There is not any current documentation @mfranzs. But my goal is to release the latest main branch this week. Although I should note that it will likely be release as a new major version 10.0.0.

[mfranzs]

Thank you very much!

[legobeat]

@lukekarrys any chance we can actually get a 9.x release? LMK if you see any blockers or other things you would need assistance with to make that happen.

^9.x is still dependended on by various unmaintained widely used ecosystem packages..

[DeeDeeG]

Stuff to consider doing before releasing?

EDIT: Besides @legobeat's point above (which I don't want to bury with my comment so shortly after)... Might want to resolve concerns mentioned in #2857 (comment) before releasing?

This bit:

Seems like the check [OP linked to in their comment] should be !=, not <. Otherwise changes requiring bumping installVersion have to be backwards-compatible due to the aforementioned scenario, which doesn't seem reasonable. If the installVersion do not match it seems reasonable to force a reinstall.

Would be good not to impose backward-compatibility guarantees on any stuff that depends on a particular installVersion matching, I think? And it's a ~3 character diff to fix it. I can do a PR going off of that person's comment if wanted. (Or the folks from that PR might have input if they were pinged, I guess.)

---

How to release / How to set the semver for the release

And (at least for stuff that happens on GitHub) the release process is basically https://github.com/google-github-actions/release-please-action#readme --> https://github.com/googleapis/release-please#readme. (And after that, I'm sure some maintainer(s) here know about how publishing the new version to the npm package registry works.)

You can manually set the version number (like 9.4.1 or 10.0.0) for release-please to follow by adding a commit with Release-As: x.x.x in the body of the commit message (below the first line)
https://github.com/googleapis/release-please#how-do-i-change-the-version-number

I did the PR to add release-please to this repo at the request of multiple active node-gyp contributors at the time, so if I can be of help by answering questions why it was set up any particular way I am happy to do so, but it was set up kind of arbitrarily just to make releases more automated than the existing process, to put it in a nutshell.

[lukekarrys]

I'm going to close this release PR so that when #2917 lands in release/v9, the new release-please action for that branch will create this v9.4.1 PR. And then I will push a new commit (as mentioned above #2878 (comment)) to create a v10.0.0 PR.

We can also use the new v10.0.0 PR to discuss any other changes that should land before the semver major is released.

[github-actions]

🤖 I have created a release *beep* *boop*

9.4.1 (2023-10-27)

Bug Fixes

• create Python symlink only during builds, and clean it up after (#2721) (0f1f667)

Core

• find python checks order changed on windows (#2872) (b030555)

Tests

• increase mocha timeout (#2887) (445c28f)
• update expired certs (#2908) (5746691)

Doc

• Add note about Python symlinks (PR 2362) to CHANGELOG.md for 9.1.0 (#2783) (b3d41ae)
• README.md Do not hardcode the supported versions of Python (#2880) (bb93b94)
• Update windows installation instructions in README.md (#2882) (c9caa2e)

---

This PR was generated with Release Please. See documentation.

[lukekarrys]

This shouldn't be released in it's current state. #2770 landed with a breaking change but isn't formatted like a conventional commit, so it didn't trigger this PR to be 10.0.0 as it should be.

[legobeat]

@lukekarrys Do you think we can consider #2849 for inclusion into a 9.4.1? Given that #2796 got included in 9.4.0 and is actually breaking Node 12.x support (#2873).

Then a more long-term solution which doesn't need to consider 12.x support can be targeting a 10.x release.

[Trott]

If someone does git commit --allow-empty -m "chore: release 10.0.0" -m "Release-As: 10.0.0" and pushes that to the main branch, I think Release Please will either update this PR or open a new one to release this stuff as 10.0.0. I think.....

[mfranzs]

Hi - is there any documentation on release processes here / when we can hope the latest main will be released? There are some critical fixes breaking Electron builds that we're waiting for. Thank you for this package!

[lukekarrys]

There is not any current documentation @mfranzs. But my goal is to release the latest main branch this week. Although I should note that it will likely be release as a new major version 10.0.0.

[mfranzs]

Thank you very much!

[legobeat]

@lukekarrys any chance we can actually get a 9.x release? LMK if you see any blockers or other things you would need assistance with to make that happen.

^9.x is still dependended on by various unmaintained widely used ecosystem packages..

[DeeDeeG]

Stuff to consider doing before releasing?

EDIT: Besides @legobeat's point above (which I don't want to bury with my comment so shortly after)... Might want to resolve concerns mentioned in #2857 (comment) before releasing?

This bit:

Seems like the check [OP linked to in their comment] should be !=, not <. Otherwise changes requiring bumping installVersion have to be backwards-compatible due to the aforementioned scenario, which doesn't seem reasonable. If the installVersion do not match it seems reasonable to force a reinstall.

Would be good not to impose backward-compatibility guarantees on any stuff that depends on a particular installVersion matching, I think? And it's a ~3 character diff to fix it. I can do a PR going off of that person's comment if wanted. (Or the folks from that PR might have input if they were pinged, I guess.)

---

How to release / How to set the semver for the release

And (at least for stuff that happens on GitHub) the release process is basically https://github.com/google-github-actions/release-please-action#readme --> https://github.com/googleapis/release-please#readme. (And after that, I'm sure some maintainer(s) here know about how publishing the new version to the npm package registry works.)

You can manually set the version number (like 9.4.1 or 10.0.0) for release-please to follow by adding a commit with Release-As: x.x.x in the body of the commit message (below the first line)
https://github.com/googleapis/release-please#how-do-i-change-the-version-number

I did the PR to add release-please to this repo at the request of multiple active node-gyp contributors at the time, so if I can be of help by answering questions why it was set up any particular way I am happy to do so, but it was set up kind of arbitrarily just to make releases more automated than the existing process, to put it in a nutshell.

[lukekarrys]

I'm going to close this release PR so that when #2917 lands in release/v9, the new release-please action for that branch will create this v9.4.1 PR. And then I will push a new commit (as mentioned above #2878 (comment)) to create a v10.0.0 PR.

We can also use the new v10.0.0 PR to discuss any other changes that should land before the semver major is released.

[github-actions]

🤖 I have created a release *beep* *boop*

9.4.1 (2023-10-27)

Bug Fixes

• create Python symlink only during builds, and clean it up after (#2721) (0f1f667)

Core

• find python checks order changed on windows (#2872) (b030555)

Tests

• increase mocha timeout (#2887) (445c28f)
• update expired certs (#2908) (5746691)

Doc

• Add note about Python symlinks (PR 2362) to CHANGELOG.md for 9.1.0 (#2783) (b3d41ae)
• README.md Do not hardcode the supported versions of Python (#2880) (bb93b94)
• Update windows installation instructions in README.md (#2882) (c9caa2e)

---

This PR was generated with Release Please. See documentation.

[lukekarrys]

This shouldn't be released in it's current state. #2770 landed with a breaking change but isn't formatted like a conventional commit, so it didn't trigger this PR to be 10.0.0 as it should be.

[legobeat]

@lukekarrys Do you think we can consider #2849 for inclusion into a 9.4.1? Given that #2796 got included in 9.4.0 and is actually breaking Node 12.x support (#2873).

Then a more long-term solution which doesn't need to consider 12.x support can be targeting a 10.x release.

[Trott]

If someone does git commit --allow-empty -m "chore: release 10.0.0" -m "Release-As: 10.0.0" and pushes that to the main branch, I think Release Please will either update this PR or open a new one to release this stuff as 10.0.0. I think.....

[mfranzs]

Hi - is there any documentation on release processes here / when we can hope the latest main will be released? There are some critical fixes breaking Electron builds that we're waiting for. Thank you for this package!

[lukekarrys]

There is not any current documentation @mfranzs. But my goal is to release the latest main branch this week. Although I should note that it will likely be release as a new major version 10.0.0.

[mfranzs]

Thank you very much!

[legobeat]

@lukekarrys any chance we can actually get a 9.x release? LMK if you see any blockers or other things you would need assistance with to make that happen.

^9.x is still dependended on by various unmaintained widely used ecosystem packages..

[DeeDeeG]

Stuff to consider doing before releasing?

EDIT: Besides @legobeat's point above (which I don't want to bury with my comment so shortly after)... Might want to resolve concerns mentioned in #2857 (comment) before releasing?

This bit:

Seems like the check [OP linked to in their comment] should be !=, not <. Otherwise changes requiring bumping installVersion have to be backwards-compatible due to the aforementioned scenario, which doesn't seem reasonable. If the installVersion do not match it seems reasonable to force a reinstall.

Would be good not to impose backward-compatibility guarantees on any stuff that depends on a particular installVersion matching, I think? And it's a ~3 character diff to fix it. I can do a PR going off of that person's comment if wanted. (Or the folks from that PR might have input if they were pinged, I guess.)

---

How to release / How to set the semver for the release

And (at least for stuff that happens on GitHub) the release process is basically https://github.com/google-github-actions/release-please-action#readme --> https://github.com/googleapis/release-please#readme. (And after that, I'm sure some maintainer(s) here know about how publishing the new version to the npm package registry works.)

You can manually set the version number (like 9.4.1 or 10.0.0) for release-please to follow by adding a commit with Release-As: x.x.x in the body of the commit message (below the first line)
https://github.com/googleapis/release-please#how-do-i-change-the-version-number

I did the PR to add release-please to this repo at the request of multiple active node-gyp contributors at the time, so if I can be of help by answering questions why it was set up any particular way I am happy to do so, but it was set up kind of arbitrarily just to make releases more automated than the existing process, to put it in a nutshell.

[lukekarrys]

I'm going to close this release PR so that when #2917 lands in release/v9, the new release-please action for that branch will create this v9.4.1 PR. And then I will push a new commit (as mentioned above #2878 (comment)) to create a v10.0.0 PR.

We can also use the new v10.0.0 PR to discuss any other changes that should land before the semver major is released.