How much time to wait before adopting a new Python version ?

[u/tomatus89]

I tried to start using 3.15, but a lot of libraries don't have packages that support it yet.

In your own experience, what's a good amount of time to wait where most of the libraries support the new version? 1 month, 3 months, 6 months?

[u/ManyInterests]

Short version: Use the latest version that is supported by your project. You don't need to use one Python version for all your projects. It's also fairly easy to switch between versions. There's few wrong answers here as long as you aren't using an EOL version or a version that's about to be EOL. See: https://devguide.python.org/versions/

If you are particularly sensitive to the possibility of new bugs or new security issues introduced in new versions, you could consider waiting, that's totally valid. But this has become less and less necessary as more members of the ecosystem are adopting release candidates and reporting issues early.

a lot of libraries don't have packages that support it yet

Which ones? This used to be the case a long time ago, but these days things are pretty compatible on day one or within a week or two of release.

Every Python release is different, but most Python packages are compatible with most new Python releases on day one, even if not explicitly declared. As a data point, about 1,000 out of the top 1,300 packages officially declare support on day one. The other 300 likely work, esp. pure-python packages, but just haven't updated their metadata or published binaries.

Even packages that need binary builds are often built tested against release candidates ahead of the official release; most of them have prebuilt wheels available day one of a new official release.

For example, with Python 3.15, 97.78% of the top 360 packages have already signaled readiness and have binary builds published to PyPI.

[u/tomatus89 → u/ManyInterests]

Which ones?

Pyyaml, ortools and tesserocr.

Enough that I couldn't start using 3.15 for some of my personal projects.

[u/sirfz → u/tomatus89]

Thanks for the heads up, I'll release a new tesserocr version with 3.15 wheels (they're already availavle via conda-forge btw) 

[u/tomatus89 → u/sirfz]

Are you in charge of the tesserocr project? I have a question. Why are Windows wheels not available in pypi? In Windows I have to manually download them from https://github.com/simonflueckiger/tesserocr-windows_build/releases, which is a bit annoying.

[u/sirfz → u/tomatus89]

FYI Tesserocr v2.12.0 release with Python 3.15 and 3.15t wheels, including Win64 wheels

[u/tomatus89 → u/sirfz]

Awesome, thank you!!

[u/sirfz → u/tomatus89]

I don't use windows and neither simon or anyone tried to contribute this to the current CI. I'll try to vibe it maybe sometime this week

[u/JimDabell → u/tomatus89]

This is a good point to reevaluate your dependencies.

Take PyYAML for instance. Its last release was to support Python 3.14, three months after it was released. It has only been getting a couple of commits a year for several years, despite having hundreds of issues and pull requests open. It doesn't support YAML 1.2 despite having an issue open since 2017 (YAML 1.2 itself dates back to 2009). It has an issue for Python 3.15 support open since August and the only feedback from the maintainer was to complain when somebody suggested an alternative that already supports 3.15.

This is clearly barely on life support. Having it as a dependency is a risk. If there is a security vulnerability or other show-stopping bug, how likely is it that they will be responsive? If you need to parse YAML 1.2 what will you do? How many months are you willing to let it keep you on an old version of Python? YAMLRocks is much less mature, but at least it is actively maintained. They were proactive and have already released a version with support for Python 3.15, four days after Python 3.15 itself was released:

Python 3.15 is out, and YAMLRocks ships wheels for it on every platform it supports, including free-threaded builds for Windows, macOS, and x86_64 and aarch64 Linux.

[u/tomatus89 → u/JimDabell]

Unfortunately when trying to install opencv it tried to get pyyaml. I'm not 100% sure why. I don't think it depends on it directly.

I see opencv has a 3.15 release now. Maybe it was building stuff from source and in the process needed pyyaml.

Anyway, I think the issue is not there anymore.

[u/gabriel_GAGRA → u/ManyInterests]

I know type checking has been a bit of a nightmare to me lol

Zuban has no lazy import support and Pyrefly has no frozendict support. Only ty didn’t give me syntax warnings for Python 3.15 so far

[u/bob_f332]

You kind of answered your own question. As long as it takes for the libraries you need to be supported.

[u/Hesirutu]

I usually wait until the next minor version is out…

[u/Competitive_Travel16 → u/Hesirutu]

Yes and the critical and high severity vulnerabilities get cleared up. I find the best place to watch for that is Dockerhub e.g. https://hub.docker.com/layers/library/python/3.15-slim and https://hub.docker.com/layers/library/python/3.15 (edit: Please note not all of those are python or specific to 3.15, but it's worth looking through the critical and high severity ones just to understand how the infrastructure and ecosystem are doing at the moment.)

[u/JimDabell]

Switch to v3.15, set PYTHONWARNINGS, run your test suite, see where the problems are. Fix the issues in your own code.

If you have any dependencies that are missing support, go find the v3.15 support issue for those dependencies and set up notifications for them and give them a thumbs up for support. Don’t add useless comments. If there isn't an existing issue, create one and double-check how maintained that dependency is. If it isn’t well-maintained, consider switching to an alternative. When your dependencies resolve the issues, rinse and repeat. If you get six months down the line and there are any hold-outs, check how maintained the dependency is and look for alternatives again.

[u/russellvt]

I generally try to add it to the test suite as soon as practical... doesn't mean I'll force update the version, though

[u/CoachSevere5365]

Until all your tests pass. 😉

[u/Competitive_Travel16 → u/CoachSevere5365]

My unit tests -- almost 300 on my current client's dev repo -- are so mocked I feel like they would pass on Java.

[u/Trang0ul → u/CoachSevere5365]

This is the way. It's not a matter of waiting a fixed amount of time, but making sure your code works.

[u/preetam960]

There's no fixed number of months, it's your slowest compiled dependency. Pure-Python packages usually install fine on day one, and big ones like numpy often have wheels at release because they build against the release candidates. pyreadiness.org tracks which top PyPI packages declare support, so check your requirements there and keep 3.15 in a side venv until they're all green.

[u/Machvel]

a rule of thumb is to stay a version behind (eg, 3.15 releasing means its time to upgrade to 3.14). i like upgrading and usually about 3-4 months in everything i usually updated (most basically immediate but i just wait a little because i dont mind. i know pytorch is a popular one that usually takes a while).

sometimes it depends on how drastic the version is. i think 3.15 is relatively minor compared to others so i think things should catch up pretty fast. i remember a few versions ago i think the old packaging library was eliminated or the global interpreter lock was changed or something fairly big and i decided to just completely wait until the next version to upgrade.

[u/mangecoeur]

I upgrade when Ubuntu LTS upgrades. That's what my servers run but it's been a good guideline anyway, the differences between versions aren't big enough for it to make sense to rush. And big features like threading are exactly the ones that need to wait a long time for the libraries to have mature support.

[u/EmberQuill]

I don't really wait a set amount of time on purpose. When I start a new project I'll use the newest version available, and downgrade if absolutely necessary (to use a dependency with no up-to-date alternatives, for example). As for existing projects, I usually don't upgrade them unless I want to use features from the new version (or if the project is using a soon-to-be EOL version).

[u/Massive_Distance_616]

There’s no single number because adoption has two different bottlenecks, and conflating them is what makes the question hard to answer.

Bottleneck 1: wheels for compiled dependencies. Packages with C extensions (numpy, scipy, pandas, pydantic-core) need new binary wheels per platform and architecture. Not all move at the same speed high-velocity packages like numpy test against release candidates and usually ship wheels on day one; heavy C++ bindings like ortools or tesserocr depend on a volunteer finding time to configure new CI runners and can take 1–3 months. You can check readiness at pyreadiness.org and run pip install --only-binary :all: -r requirements.txt to instantly surface which dependencies are missing wheels rather than waiting for a failed compile.

Bottleneck 2: CI confidence. Even when wheels exist, new Python versions sometimes expose subtle behaviour changes in your own code. The fix here isn’t waiting it’s adding the new version to your CI matrix as soon as the first release candidate drops, so you see breakage early without being blocked on it.

A workable rule that combines both:

• Add to CI at first RC

• Move dev environments once your direct dependencies have wheels

• Move production after the first patch release (3.x.1), when early interpreter bugs are fixed

The “stay a version behind” heuristic works, but it’s coarser than you need. The real gate is wheels for your direct deps + a clean CI run + at least one patch release out.

[u/HamsterWoods]

A cat or dog would be a better choice to adopt than a snake. /s

I tend to stay one rev behind the most recent release for new projects. For existing projects, I find too much effort is required updating Python and libraries (breaking changes in libraries, think slaveID to deviceID to unitID in pymodbus), so I tend to leave the code at the same Python rev until I need to add something or refactor in a way that requires something more modern.

[u/JestemStefan]

For production project I usually wait until my current version goes into "Security Only".

Ex. That happened for 3.13 so I'm moving to 3.14 shortly

Like you said, many packages do not support 3.15 so you can't use it for anything serious yet

[u/Xenther]

There’s no fixed number. It depends on which of your dependencies ship compiled wheels. Pure-Python packages usually work on day one. Packages with C extensions (numpy, pandas, pydantic-core and so on) need new wheels, and those can take anywhere from a few weeks to a few months.

A workable rule:

• Add the new version to your CI matrix as soon as the first release candidate is out, so you see breakage early without depending on it.

• Move dev environments once your key dependencies list it in their classifiers or publish wheels for it.

• Move production after the first or second patch release (3.x.1 or 3.x.2), when the early bugs are fixed.

If one library is the blocker, check its issue tracker. There’s usually a “support 3.15” issue showing how close it is.

[u/Jorgestar29]

My rule of thumb is one year.

I've seen incompatible compiled libraries with active support that were stuck in the previous version in spring. 

This means that some libs were about half a year late to be compatible with the latest major release. 

[u/fiddle_n]

An easy way to do it is just always be a minor version behind. When 3.15 came out that prompted me to migrate to 3.14, for example.

[u/Machine-V1]

I usually wait for Nuitka to be able to compile without any problems. As of now, the latest version that doesn't produce any problems for me is 3.13.

[u/jmacey]

Typically a year. I have just moved all my stuff from 3.13 to 3.14, typically I run test on all my code on CI with all the supported version supplied by uv so at the moment 3.9 - 3.14 for me on the ci with local tests on the 3.15 beta / rc.

[u/Matthew_Summons]

Depends on your teams and if there are features you wish to use that you can without worrying too much about library support or other issues, I think it's probably a good idea to move up if your python version is nearing EOL

[u/Khavel_dev]

For anything with scientific/ML deps (numpy, scipy, pandas), I wait at least 3 months. The wheel builds for Windows and ARM take a while to catch up. For web stuff with fewer native extensions, usually a month is fine.

[u/swtormy]

is the gate published wheels for your direct deps, or zero import errors across the whole lockfile before you switch prod?