Python 3.14 is not accepted in Branches v20.x, v22.x & v24.x

[richardlau]

Note that Python 3.14 is not accepted in Branches v20.x, V22.x & V24.x when using Visual Studio 2022. The error message is:

Please use python3.13 or python3.12 or python3.11 or python3.10 or python3.9 or python3.8 or python3.7 or python3.6.

This is however a separate issue. It also affects building on Linux with Fedora 43 (latest Fedora version) using the system-default version of Python (3.14).

Originally posted by @MikeMcC399 in #60869

cc @nodejs/releasers @nodejs/lts

(Disregard the Visual Studio 2022 bit, that's irrelevant for the Python issue. )

#59983 was marked dont-land-* for 25.x, 24.x, 22.x and 20.x but I think we do want the configure changes on the earlier release lines (provided no compatibility breakage with Python 3.14). I don't think we want the allow-prereleases change to the workflows (maybe that was the reason for the dont-land-* labels?).

[MikeMcC399]

@richardlau

I wasn't really sure whether this should be reported as an issue, which is why I just wrote it as a comment in #60869

If you think it would be helpful I can write up steps to reproduce using Fedora 43, which has Python 3.14 as default. It is however simple to install other versions, such as Python 3.13 on Fedora - see https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html - so a workaround is available in this case.

[richardlau]

The usual workaround is to bypass configure and run instead python3 configure.py (or python3.14 configure.py) which avoids any version sniffing. However as Python 3.14 becomes more commonplace, I think at least the more recent Node.js release lines ought to be able to autodetect it.

[aduh95]

Should we just backport #59983?

[MikeMcC399]

@aduh95

Should we just backport #59983?

I backported #59983 to the v24.x-staging branch locally and then successfully built Node.js on a Fedora 43 system with the default Python 3.14 installed.

I would offer to submit this as a PR, however I would wait until after the security release to avoid complications. Does this make sense or would you prefer to handle the backporting yourself?

[aduh95]

It's alright if you open it now, I would recommend rebasing on top of v24.x to not be affected by the security release.

[MikeMcC399]

@aduh95

It's alright if you open it now, I would recommend rebasing on top of v24.x to not be affected by the security release.

Did I understand you correctly, that I should cherry-pick into the v24.x branch and then the PR should also target the v24.x branch?

(I was so far just following the instructions in How to backport a pull request to a release line which describes using the corresponding vN.x-staging branch.)

It may be simpler just to wait the 2 or 3 days until after the security release, so I can just follow standard process, bearing in mind also that this would be my first backporting PR.

[aduh95]

Backport PRs should always target the staging branch (i.e.v24.x-staging, which is always ahead of v24.x). My recommendation is to rebase the backport on top of the tip of v24.x but still tarhet v24.x-staging. Obviously timing is up to you, do as you see fit.

[MikeMcC399]

To avoid any additional complications I'll wait until after the release.

I don't see the backport as an urgent need since mainstream Linux such as Debian and Ubuntu are still on Python 3.12 / 3.13 as default. Although Fedora has Python 3.14 as default, it offers easy installation for earlier versions. On Windows it's also easy to install Python 3.13 as well, even though it's no longer Python's default.

So this is more just covering bases for future months and years.

[MikeMcC399]

I've now submitted #61370 for v24.x

[MikeMcC399]

I would also offer to prepare the backports for v20.x and v22.x. I would wait first for the successful acceptance of the v24.x backport #61370 before opening any other new PR though.

[aduh95]

I would also offer to prepare the backports for v20.x and v22.x

Unless the commit that will land on v24.x does not apply on the other lines, we don't need backport PRs, a releaser or backporter can simply cherry-pick it; in fact it's less work for everyone if we skip the backport PR, so that would be my preference.

[MikeMcC399]

Unless the commit that will land on v24.x does not apply on the other lines, we don't need backport PRs, a releaser or backporter can simply cherry-pick it; in fact it's less work for everyone if we skip the backport PR, so that would be my preference.

Attempting to backport from v24.x-staging to v22.x-staging requires manual resolution of merge conflicts in android-configure and configure due to v22.x allowing Python 3.8 which v24.x does not allow.

The conflicts aren't difficult to resolve. Would this be a task typically done by a backporter or would it require a separate backport PR?

[MikeMcC399]

PR #58752 (dfcb824), which updated tools/configure.d/nodedownload.py for Python 3.14 compatibility, was backported to

• 24.3.0
• 22.18.0

not to the v20.x branch, so that would be a blocker to backporting #59983 to v20.x.

Given the impending EOL of Node.js 20 in April 2026, and the limited advantage of making this branch compatible with Python 3.14, I suggest to drop it as a target for this issue.