NumPy 2.0 Reaches End of Life on June 17, 2026

NumPy 2.0 reaches end of life on June 17, 2026. After that date, the 2.0.x line stops receiving releases of any kind — no bug fixes, no security patches.

If you migrated off NumPy 1.x to escape its September 2025 end of life, this will feel familiar. That's because it is. NumPy retires versions on a rolling schedule, and 2.0 is simply the next one up.

‍

What's actually ending

To be precise: this is NumPy 2.0, not NumPy 2.x as a whole. The 2.x series is current and well-maintained. NumPy 2.4 shipped in December 2025, with 2.4.6 released in May 2026. Versions 2.1 through 2.4 all remain in support.

What ages out on June 17 is the 2.0.x line specifically — the major release that landed on June 16, 2024 and last saw a patch (2.0.2) that August.

The reason is policy, not abandonment. NumPy follows SPEC 0, the support standard shared across the scientific Python ecosystem. Under SPEC 0, a minor version is supported for roughly 24 months after release, and at minimum the last three minor versions stay supported. NumPy 2.0 is hitting that 24-month mark. Every NumPy minor before it has aged out the same way, and every one after it will too.

‍

The treadmill nobody signed up for

Here is the part worth sitting with.

A lot of teams spent late 2024 and 2025 doing the painful work of moving off NumPy 1.x. NumPy 2.0 was the first major release since 2006, and it broke things — the ABI changed, and both the Python and C APIs shifted. Downstream packages and end-user code had to be adapted. That migration was not free.

The teams that did it landed on 2.0. And 2.0 is now the version going end of life.

This is the structural reality of SPEC. Support windows roll forward continuously. Stand still for two years and whatever you're pinned to ages out from under you. The migration you just finished buys you about 24 months before the next one starts.

‍

Why an EOL NumPy is a real exposure

NumPy is not an optional dependency. It sits underneath pandas, scikit-learn, SciPy, PyTorch, TensorFlow, and most of the data and ML stack. When a version goes unsupported, three things follow:

• No security patches. Any CVE disclosed against 2.0 after June 17 stays unpatched. You inherit it.
• A foundational blast radius. A vulnerability in a base numerical library can reach deep into anything built on top of it. This is the kind of transitive dependency auditors ask about.
• Compliance pressure. For teams in finance, healthcare, or government, running EOL components is not just a risk — it's often a finding. "We're on an unsupported version of a core library" is a hard line item to defend.

None of this is hypothetical urgency. It's the same math that made 1.x EOL a problem nine months ago, applied to the version that replaced it.

‍

Your options

There are three honest paths, and they trade off differently.

Upgrade to a supported 2.x. Moving from 2.0 to 2.1–2.4 is far gentler than the 1.x-to-2.0 jump was — the big breaking change was 2.0 itself, and minor upgrades within 2.x are comparatively routine. The catch is rarely NumPy. It's the pinned transitive dependencies in your tree. If a library you rely on caps NumPy at <2.1, you don't get to choose. That single pin is usually what keeps teams stranded on an old version.

Pin and accept the risk. You can stay on 2.0 and absorb the exposure. For some internal, low-stakes workloads that's a defensible call. For anything regulated or internet-facing, it usually isn't.

Get extended support. If a clean upgrade isn't realistic on this timeline — because of a frozen dependency, a validated pipeline you can't disturb, or a release calendar that doesn't have room — you can keep receiving security fixes for the version you're on while you plan the move on your terms.

‍

Staying secure without the scramble

This is the gap HeroDevs Never-Ending Support is built for. We deliver security patches for end-of-life open source — including NumPy — so an EOL date stops being a deadline you have to sprint toward.

The point isn't to keep you on old NumPy forever. It's to decouple "this version is unsupported upstream" from "we have to drop everything and migrate right now." You get continued security coverage, you stay compliant, and you move when your stack and your team are actually ready.

NumPy 2.0 goes end of life on June 17. The next version's clock is already running.

Talk to us about Never-Ending Support for NumPy →