[v24.x backport] build: test on Python 3.14

[MikeMcC399]

Python v3.14 -- October 7th

• https://www.python.org/download/pre-releases
• https://www.python.org/downloads/release/python-3140rc3

PR-URL: #59983
Reviewed-By: Marco Ippolito marcoippolito54@gmail.com
Reviewed-By: Stefan Stojanovic stefan.stojanovic@janeasystems.com
Reviewed-By: Stewart X Addison sxa@redhat.com

---

Ref: #60874

Situation

Node.js 24.x (Active LTS) build fails with Python 3.14.

Python 3.14 is:

• the current highest supported Python version
• the system-default on Fedora 43
• the version installed on Windows using py install default

Change

Backports #59983 (commit 8bc7dfd) to v24.x branch.

The commit message from the backport should be modified, removing the outdated "release candidate 3" text. It is currently:

build: test on Python 3.14 release candidate 3

Python 3.14 was released as GA on 2025-10-07 and is therefore no longer pre-release.

[nodejs-github-bot]

Review requested:

• @nodejs/actions
• @nodejs/security-wg

[aduh95]

Please remove, as requested in #60874 (comment)

[MikeMcC399]

I'm happy to remove it, if the Node.js team things that is best.

I initially left it in because otherwise the v24.x branch would be inconsistent with the v25.x branch, which includes this parameter. Also it's a no-op so long as the workflow sets PYTHON_VERSION: '3.14' which is a released version.

For example https://github.com/nodejs/node/blob/v25.x/.github/workflows/build-tarball.yml includes the allow-prereleases: true parameter setting.

Perhaps it should be removed from v25.x and then from any backporting to v24.x, v22.x & v20x? Then they'd all be consistent. Or maybe they don't need to be consistent?

Please let me know if I should remove it or leave it in, based on the above comments.

cc: @richardlau who wrote in #60874

I don't think we want the allow-prereleases change to the workflows (maybe that was the reason for the dont-land-* labels?).

[aduh95]

If we keep the original change, we wouldn't need a backport PR, a releaser would simply cherry-pick the commit when preparing the next release. There are two possible outcomes:

• we want to have allow-prereleases on v24.x, in which case we can close this PR.
• we don't want to have allow-prereleases (as suggested by Richard already), in which case this PR needs updating.

So you should definitely remove it, and then it can be discussed whether we want to close the PR or merge (i.e. to have allow-prereleases on v24.x or not).