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
Continued use of Python 3.10 in Jenkins Windows systems causes failure of open PR nodejs/node#66662 intended to drop the end-of-life Python 3.10 from support in the main branch of Node.js.
Hey Mike, yes, we are pinned at 3.10.8. This was a long time ago (back in 2022), as I see in this comment about making that change: "Node.js 14 is incompatible with Python 3.11. Pin Python 3 to 3.10.8."
Now, I'm not sure whether we want to remove the pin completely or stick to an exact 3.14 version, but ideally we should move to Python 3.14. The issue with not pinning is that it can break builds more often, but we will also miss any potential changes released later. I'm OK with any of those approaches, and I'll make the changes in the CI (and in the Ansible script), so @nodejs/platform-windows feel free to argue for one or the other approach before moving forward with this.
Since Python actively removes deprecated APIs I would not want it to automatically get updated on the machines as it could easily break builds of the older release lines (e.g. Node.js 22). I don't know if we can pin within a Python version (e.g. 3.14.x), which I would be okay with, or would need to be specific (e.g. 3.14.8).
We can also do this - install the python314 Chocolatey package, so basically have 3.10 and 3.14 side by side. The issue with that is this: currently, vcbuild.bat will pick the first Python it sees, so it depends on the order in which they were installed. I'm thinking of improving the find Python logic to look until it finds the supported Python version (should be simple enough to do). After we do that, the latest version would use Python 3.14, and we can backport Python 3.10 dropping if we want to use it for LTS versions too.
What did you mean by backporting Python 3.10 dropping? What would be the target(s) of the backport?
My understanding of the support strategy for EOL Python versions is that dropping Python 3.10 support in the release lines should only be targeted to the future Node.js 27 and not backported to existing release lines 26, 24 & 20 (see also table in the original post).
Activity
MikeMcC399 commentedon Oct 11, 2026
It looks like this would be from:
build/ansible/roles/baselayout-windows/tasks/main.yml
Lines 15 to 27 in 0cebb10
Possibly pin instead to Python 3.14.8 ?
StefanStojanovic commentedon Oct 14, 2026
Hey Mike, yes, we are pinned at 3.10.8. This was a long time ago (back in 2022), as I see in this comment about making that change: "Node.js 14 is incompatible with Python 3.11. Pin Python 3 to 3.10.8."
Now, I'm not sure whether we want to remove the pin completely or stick to an exact 3.14 version, but ideally we should move to Python 3.14. The issue with not pinning is that it can break builds more often, but we will also miss any potential changes released later. I'm OK with any of those approaches, and I'll make the changes in the CI (and in the Ansible script), so @nodejs/platform-windows feel free to argue for one or the other approach before moving forward with this.
richardlau commentedon Oct 14, 2026
Since Python actively removes deprecated APIs I would not want it to automatically get updated on the machines as it could easily break builds of the older release lines (e.g. Node.js 22). I don't know if we can pin within a Python version (e.g. 3.14.x), which I would be okay with, or would need to be specific (e.g. 3.14.8).
StefanStojanovic commentedon Oct 14, 2026
I do not think Chocolatey allows partial pins, eg. 3.14.x, but there is this package, which can effectively do that: python314
sxa commentedon Oct 14, 2026
Is it worth snapshotting/cloning one of the existing machines to test it so we can get back to the original state if needed?
StefanStojanovic commentedon Oct 15, 2026
We can also do this - install the
python314Chocolatey package, so basically have 3.10 and 3.14 side by side. The issue with that is this: currently,vcbuild.batwill pick the first Python it sees, so it depends on the order in which they were installed. I'm thinking of improving the find Python logic to look until it finds the supported Python version (should be simple enough to do). After we do that, the latest version would use Python 3.14, and we can backport Python 3.10 dropping if we want to use it for LTS versions too.MikeMcC399 commentedon Oct 15, 2026
What did you mean by backporting Python 3.10 dropping? What would be the target(s) of the backport?
My understanding of the support strategy for EOL Python versions is that dropping Python 3.10 support in the release lines should only be targeted to the future Node.js 27 and not backported to existing release lines 26, 24 & 20 (see also table in the original post).