EOL: Drop support for Python 3.9 and below

[DhavalGojiya]

Summary

As of 2025-10, Python 3.9 is end of life and does not get upstream support from python.org anymore.

This PR drops support for Python 3.9 and below to align with the current Python ecosystem and simplify code maintenance.

Python 3.9 reached end of life: https://devguide.python.org/versions/

---

Changes

• Added python_requires=">=3.10" in setup.py
• Removed references and compatibility for older Python versions
• Update project manager Pipenv with Python 3.10+
• Update GitHub Actions CI/CD workflow to drop Python 3.9
• Update README

---

Notes

Users on Python versions earlier than 3.10 will now receive a version restriction error when trying to install Pysolr version 3.11 or higher via pip.

[cclauss]

pysolr/.github/workflows/tox.yml

Lines 11 to 13 in 2a8ec8d

	max-parallel: 5
	matrix:
	python: ["3.9", "3.10", "3.11", "3.12", "3.13", "3.14", "3.14t"]

Please remove the max-parallel: 5 line and also 3.9 so the tests pass.

[acdha]

Historically we haven't rapidly dropped support for Python versions when there are still Linux distributions which have years of support for those versions (e.g. Red Hat / Amazon Linux / etc. are multiple years away, Debian Bullseye is a year) but it's not unreasonable to say that people using those with the default versions are probably not tracking the latest Pysolr either. Let's plan to tag this as 3.11 or perhaps 4.0 so it's easy to backport something like a security update.

[DhavalGojiya]

Historically we haven't rapidly dropped support for Python versions when there are still Linux distributions which have years of support for those versions (e.g. Red Hat / Amazon Linux / etc. are multiple years away, Debian Bullseye is a year) but it's not unreasonable to say that people using those with the default versions are probably not tracking the latest Pysolr either. Let's plan to tag this as 3.11 or perhaps 4.0 so it's easy to backport something like a security update.

So the future flow is:

1. This PR: Drop support for Python 3.9 and merge into master
2. We can release PySolr 3.11 (Minor bump)
3. If security/critical patches are needed for Python 3.9 users:
   • Create a 3.10.x branch from the 3.10.0 PySolr Github tag
   • Backport security/critical patches from master to that branch
   • Release as 3.10.1, 3.10.2, etc.
   • These 3.10.x releases continue to support Python 3.9 with additional patches
4. Meanwhile: master continues with new features and bug fixes requiring Python 3.10+

Is this the plan you have in mind?

[acdha]

Yes - that way anyone who needs to maintain Python 3.9 support (e.g. another project which itself supports multiple version of Python) can pin pysolr<3.11 and not need to worry about unintentionally dropping it.

[cclauss]

Linux distributions which have years of support for those versions

That is paid support. So if users are paying Red Hat or Amazon, then those organizations can provide the required support.

Python has fallen into a nice rhythm of having five supported versions over five years, rotating each October. If you count Python 3.13t and 3.14t, that is 7 versions that need to be supported, plus optionally PyPy 3.11. I think that supporting up to 8 different versions is enough work for open source teams that receive no remuneration.

It is not a good idea for people to build systems on software that contains carefully documented security flaws but no longer receives security updates. A lot of recent work has gone into making Python faster. Those who remain on EOL versions see none of that progress, and so they might consider porting rather than upgrading.

[DhavalGojiya]

Let's plan to tag this as 3.11 or perhaps 4.0, so it's easy to backport something like a security update.

I strongly recommend that we bump the major version, e.g. pysolr 4.0.0

Here are my points to support this statement:

• A major version bump directly indicates that we introduced a significant change.
• Suppose tomorrow Apache Solr introduces a new endpoint to work with core or schema - we will likely provide support for it in pysolr, right?
  In most cases, such features can also be implemented using the requests module or other built-in tools, meaning backporting them to Python 3.9 - supported versions (like pysolr 3.10.x or 3.11.x) is still possible.
• By bumping to pysolr 4.0.0, we create a clear separation from the 3.x series (3.10.x, 3.11.x, 3.12.x, etc.) that still supports Python 3.9. This allows us not only to backport security fixes but also to backport new features (via minor bumps) to those versions - while keeping 4.x focused on modern Python support.
• I am not saying that we must also backport possible new feature changes to the old 3.x.x series - as @cclauss clarified a lot of things - but we'll still have the option to do so if needed. For users running Python versions below 3.10, at least we'll have the flexibility to consider it.

[cclauss]

At this point, a major release should also include improvements like:

• Test pysolr against multiple versions of Solr, fixes #223 #227 and
• Fix extraction in Solr >= 8. #490

[acdha]

That is paid support. So if users are paying Red Hat or Amazon, then those organizations can provide the required support.

It's not necessarily paid support – only one of the examples I mentioned requires payment – but to your larger point, yes, I think we should drop support following the upstream CPython support lifecycle. I just want to do it in a way which leaves an easy pinning option for anyone depending on pysolr in a project which still supports users on those long-term stable Linux distributions.

Here are my points to support this statement: …

Was some of this written with the help of an LLM? Some of the hypotheticals or the way requests is referenced seem generic in that style and I'm not sure they're germane to a small project like Pysolr. I really don't anticipate the need to back port new features, for example, since the only reason we'd touch it would be something like an exploitable security problem.

My vote would be using a minor release (3.11). That's not a strong argument against a major release because the cost of either is low, but this isn't really changing the actual public API and as long as the package is correctly tagged people can't easily install new releases on Python 3.9. Historically we haven't had problems caused by dropping support for old Python versions in minor releases.

[DhavalGojiya]

Was some of this written with the help of an LLM?

No. I asked this in the official Django Discord server, and that's where I got my some supporting points.

[DhavalGojiya]

Some of the hypotheticals

Not hypothetical - actually, I have quite a few years of experience working with Apache Solr. I know how Solr releases new featurres along with endpoints API (v1, v2) modifications every year.

[DhavalGojiya]

Strange!
Why is the GitHub Actions workflow suddenly taking more time?

[acdha]

Strange! Why is the GitHub Actions workflow suddenly taking more time?

I believe we get hit by the quota mechanism since we don't have paid capacity.

[acdha]

Was some of this written with the help of an LLM?

No. I asked this in the official Django Discord server, and that's where I got my some supporting points.

Ah, cool, I just wasn't sure where the idea of things like back porting features came from since Pysolr is unlike a lot of other projects in that it's really just a wrapper for upstream functionality so there's much more limited scope for that kind of thing. Django Haystack might have a little more of that since there are people who might be stuck with other dependencies blocking, say, a major Django or Python upgrade but this project is mostly a shim.

[acdha]

This is looking like a very nice cleanup PR. I'm enjoying removal of all of the Python 2 checks, thank you!

[acdha]

I think we could go with this immediately. If we want to adjust the requests minimum version that can happen later.

[DhavalGojiya]

This is looking like a very nice cleanup PR. I'm enjoying removal of all of the Python 2 checks, thank you!

Welcome 🤓

[DhavalGojiya]

I think we could go with this immediately. If we want to adjust the requests minimum version that can happen later.

Ok, but we also need to update the README file. I can see that some code blocks in the README mention Python 2.x.

[DhavalGojiya]

Final Summary

Virtual Environment Graph after Dropping Python 3.9 and Below Support

$ uv pip tree        
kazoo v2.10.0
pysolr v0.1.dev630+g08588afdd.d20251113
├── requests v2.32.5
│   ├── certifi v2025.11.12
│   ├── charset-normalizer v3.4.4
│   ├── idna v3.11
│   └── urllib3 v2.5.0
└── setuptools v80.9.0