Creating a Dependency Policy

[pacrob]

The question came up while reviewing #732. We don’t want to arbitrarily raise the lower bounds of our dependencies, since that can create dependency issues for users. But we should also ensure we’re using modern, secure versions that we’ve actually tested.

A couple of proposals:

Compatibility Policy

Review our dependencies and supported Python versions on a regular basis—at least annually. The review should consider security advisories, upstream Python version support, and other relevant changes. The policy should be in our docs for contributors and users.

CI Testing of Minimum Versions

Add a CI job that installs the lowest supported versions of each dependency and verifies that the test suite still passes.

[seetadev]

@pacrob : This is a very thoughtful proposal, thank you for raising it! 👏

Completely agree - we don’t want to arbitrarily raise dependency lower bounds and cause friction for downstream users, but at the same time, we have a responsibility to ensure that the versions we claim to support are secure, modern, and actually tested in practice. The two concrete ideas you suggested strike a great balance between stability and progress:

1. Compatibility Policy
Documenting an explicit compatibility policy feels like a big step forward. It will not only give clarity to contributors and users but also make our decisions more transparent and less ad-hoc. I really like the idea of tying the review cycle to something predictable (e.g. annually) and aligning it with upstream Python lifecycle changes and security advisories. That’s a solid way to avoid drift over time.

2. CI Testing of Minimum Versions
Adding a CI job for the lowest supported versions is a fantastic idea. It makes our support claims verifiable and helps catch subtle issues early, rather than leaving users to discover them later. This also means we can be more confident when we say “we support version X of dependency Y,” because our tests actively confirm it.

Happy to see us move forward with both of these. The CI piece feels immediately actionable (and a clear win for reliability), while the compatibility policy can evolve as we draft it out and invite community input. Together, these changes will make our maintenance efforts stronger and more predictable.