Skip to content

Python 3.10 EOL 2026-10-01 used in Windows #4514

Open

Description

@MikeMcC399

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.

Python 3.10 EOL 2026-10-01

https://ci.nodejs.org/job/node-test-pull-request/78315/ failing

PR nodejs/node#66662 plans to drop support for Python 3.10 in the main branch of https://github.com/nodejs/node and for the future Node.js 27 release. This PR is currently failing in Jenkins for Windows, where jobs are attempting to run under Python 3.10.8 (see nodejs/node#66662 (comment)). Python 3.10 entered end-of-life on 2026-10-01.

Python 3.15 release 2026-10-09

PR nodejs/node#65750 landed in nodejs/node@85543c1 to update the main branch of https://github.com/nodejs/node to allow Python 3.15 and use it in GitHub Actions workflows. This is expected to be backported to release lines.

Current and future Python allowed versions

Node.js branch Current Python versions Planned Python versions
main 3.10 - 3.15 3.11 - 3.15
26.x 3.10 - 3.14 3.10 - 3.15
24.x 3.9 - 3.14 3.9 - 3.15
22.x 3.8 - 3.14 3.8 - 3.15

Python 3.11 - 3.14 would be the safe range that fits current and planned versions for all release lines and main.

Activity

  1. MikeMcC399 commented on Oct 11, 2026

    @MikeMcC399
    Author

    It looks like this would be from:

    - name: install Python 3
    win_chocolatey:
    install_args: Include_launcher=1
    name: python3
    pinned: yes
    version: "3.10.8"
    - name: install Python 3
    win_chocolatey:
    install_args: Include_launcher=1
    name: python
    pinned: yes
    version: "3.10.8"

    Possibly pin instead to Python 3.14.8 ?

  2. StefanStojanovic commented on Oct 14, 2026

    @StefanStojanovic
    Contributor

    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.

  3. richardlau commented on Oct 14, 2026

    @richardlau
    Member

    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).

  4. StefanStojanovic commented on Oct 14, 2026

    @StefanStojanovic
    Contributor

    I do not think Chocolatey allows partial pins, eg. 3.14.x, but there is this package, which can effectively do that: python314

  5. sxa commented on Oct 14, 2026

    @sxa
    Member

    Is it worth snapshotting/cloning one of the existing machines to test it so we can get back to the original state if needed?

  6. StefanStojanovic commented on Oct 15, 2026

    @StefanStojanovic
    Contributor

    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.

  7. MikeMcC399 commented on Oct 15, 2026

    @MikeMcC399
    Author

    we can backport Python 3.10 dropping

    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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions