scipy's main branch declares itself 2.0.0.dev0 while the newest release is 1.18.1

The default branch calls itself 2.0.0.dev0 and the newest release is 1.18.1

The version numbers in this repository do not describe one thing, and the gap between them is the first thing to understand.

The three most recent releases are 1.18.0rc2 as a release candidate on 2026-06-09, 1.18.0 on 2026-06-19, and 1.18.1 on 2026-08-21. So the published line is 1.18 and the patch release came about two months after the minor one.

Now the source. The project manifest on the default branch declares its version as 2.0.0.dev0. That is not a mistake in the metadata and not a stale field. A development version marker means the tree is what will become the next major release, and the default branch is where that work happens.

The default branch took a push on 2026-11-02, so the 2.0 line is being worked on now rather than abandoned.

The consequence is that a source checkout and a wheel do not report the same version, and they are not the same code. If you install from a package index you get 1.18.1. If you build the default branch you get a 2.0 development build. Pin deliberately, because a floating dependency that resolves differently between a developer's machine and a build server is the failure mode here.

The package compiles on install, so a working toolchain is a deployment requirement

SciPy is not a pure-Python package, and that changes what deploying it involves.

The build system is declared in the project manifest and names meson-python as the backend. The build requirements include a specific minimum for the Python binding generator, a minimum for pybind11, one for pythran, and a floor of NumPy 2.0.0. That list is what runs when a wheel is not available and the package has to be built from source.

There is a note at the top of that manifest explaining the convention for upper bounds. Every build dependency in a maintenance branch is supposed to carry an upper bound equal to the most recent released version of that dependency, so that a future backwards-incompatible release cannot break the source build of an existing SciPy release. Micro releases are still accepted.

That comment describes a project that expects to be built from source often enough to need a policy about it.

The consequence for deployment is concrete. On a platform where a prebuilt wheel exists for your Python version and architecture, pip resolves it and none of this applies. Where one does not, you need a compiler, the build backend and the generator before install succeeds. That is a real constraint in a locked-down or minimal container.

The scope is broad enough that the module you need is a naming question

SciPy's stated coverage spans most of applied mathematics, and the breadth is a strength and a navigation problem at the same time.

The listed areas are statistics, optimization, integration, linear algebra, Fourier transforms, signal and image processing, and ODE solvers, described as and more.

Notice what is not in that list. There is no plotting, no dataframe handling and no machine learning. SciPy is the numerical layer underneath those, not a replacement for them.

The practical consequence is that a task like fitting a curve sits in optimization, a task like summarising a dataset sits in statistics, and the boundary between SciPy and the dataframe libraries is a question of what shape your data is in rather than what you want to compute.

So when you reach for SciPy, the first decision is which of those areas owns your problem, because the import you need follows from that and not from the name of the operation you want to perform.

Bug reports are routed to a paid security channel rather than the issue tracker

One entry in the front page's link list breaks the pattern of the rest, and it is the one that matters most.

Ordinary problems go to the issue tracker on the repository. Questions go to Stack Overflow under the project's tag, and contributor discussion goes to a discussion forum under the scientific-python organisation. Documentation has a stable address and a separate development address for the unreleased version.

Security vulnerabilities are the exception. The front page routes them through Tidelift, with a pointer to the project's security documentation explaining the process.

That is a deliberate arrangement. A public issue describing a vulnerability in a numerical library is a real disclosure problem, because the library sits underneath a great deal of published scientific work. Routing reports through a dedicated channel is the responsible choice.

The consequence is procedural rather than technical. If you find a vulnerability in SciPy, do not file it on the tracker. The channel is named and documented, and using the tracker instead would publish the details before a fix exists.

For everyone else, the separation is worth knowing so that an ordinary bug and a security problem do not go to the same place.

The repository ships a type checker config and a module boundary config alongside the build

Two configuration files at the top level tell you what kind of codebase this is being maintained as.

There is a pyrefly configuration file and a tach configuration file. The first is for a static type checker aimed at Python code. The second enforces module boundaries, which in practice means the project has rules about which internal module may import which other one.

The module-boundary rule is the more interesting of the two. SciPy's source tree is large and split into subpackages for each of the areas named in the scope. Declaring that some may not import others is how a library that size keeps its dependencies acyclic, and it is a discipline that has to be enforced by tooling rather than by reviewers noticing.

The top-level listing also shows a benchmarks directory, a separate doc directory, a tools directory, a subprojects directory and a .spin directory, alongside the build files and the source itself. The .spin entry points to a task runner used during development.

The consequence is that this is a codebase with automated quality gates on structure, not only on style.

The project asks for contributions that are not code, and it has a written policy on AI

The contribution section says explicitly that writing code is not the only way in, which is unusual to see stated so plainly.

Code contributions are listed first, with issues labelled as good first issue named as a starting point. Then the non-code list: reviewing pull requests, triaging issues, developing tutorials and other educational material, maintaining the separate website repository, doing graphic design for brand assets and promotional material, helping with outreach and onboarding new contributors, and writing grant proposals and fundraising work.

Two of those are worth pausing on. Triage is listed as a distinct contribution, which for a repository with a large open issue count is a substantial need rather than a courtesy. Fundraising is listed too, which tells you something about what sustains the project.

Alongside the contribution guide there is a separate written policy on artificial intelligence, linked from the same paragraph. A project that maintains an explicit AI policy has had to decide what it permits, and the policy document is the place to read that decision rather than inferring it.

The consequence for a reader is that this is an actively run open source project with staffed process rather than a codebase awaiting a maintainer, and the front page points to where each of those activities is coordinated.

The licence is BSD-3-Clause and the bundled third-party licences are tracked in a separate file

The licensing is the permissive three-clause BSD, and the repository is explicit about tracking what is bundled with it.

The project manifest declares the licence by pointing at a licence file at the top level. There is also a separate file listing the licences of bundled third-party material, and a commented note in the manifest explaining that the licence files field cannot yet be used because the relevant packaging specification is not accepted by the build backend yet.

That note is a small window into the packaging side of the project. Declaring multiple licence files in metadata is the modern way to do this, and the manifest says it is waiting on the build backend before it can. In the meantime the bundled licences are tracked by a file in the repository rather than by metadata that tooling would read automatically.

The governance detail behind it is that this is a NumFOCUS project, which the front page shows as a badge linking to the foundation.

The consequence is practical and mild. The BSD-3-Clause licence places essentially no obligation on you beyond attribution, which makes SciPy straightforward to embed in commercial and closed-source work. The bundled-licence file is the thing to check if you are shipping a binary that includes compiled SciPy code, since that is a different question from the licence on the Python package itself.

Editorial conclusion

SciPy is the right default for numerical work in Python, and the reasons are structural rather than incidental: it operates on NumPy arrays rather than its own array type, it is a NumFOCUS project with a BSD-3-Clause licence, and its release cadence is regular enough that a maintenance branch exists to carry fixes. Two things to settle before you depend on it. Which channel you are on, because a source checkout of the default branch reports itself as a 2.0 development build while the newest published release is 1.18.1, and those are not interchangeable for pinning. And whether a compiled install is acceptable in your environment, because the build backend compiles the package and a platform with no wheel available means you need a working toolchain. Read the install guide rather than assuming pip resolves it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes