ref: Enforce minimum version in integrations

[sentrivana]

• Add _check_minimum_version calls to all integrations that had entries in _MIN_VERSIONS but were not enforcing them at runtime
• Add new _MIN_VERSIONS entries for integrations that were missing them
• Use package-provided version if possible; fallback to package_version only if not available

[github-actions]

Codecov Results 📊

✅ 90642 passed | ⏭️ 5440 skipped | Total: 96082 | Pass Rate: 94.34% | Execution Time: 325m 26s

📊 Comparison with Base Branch

Metric	Change
Total Tests	📉 -5720
Passed Tests	📉 -4921
Failed Tests	—
Skipped Tests	📉 -799

All tests are passing successfully.

✅ Patch coverage is 98.48%. Project has 2334 uncovered lines.
✅ Project coverage is 90.15%. Comparing base (base) to head (head).

Files with missing lines (2)

File	Patch %	Lines
sentry_sdk/integrations/chalice.py	66.67%	⚠️ 1 Missing
sentry_sdk/integrations/starlette.py	50.00%	⚠️ 1 Missing

Coverage diff

@@            Coverage Diff             @@
##          main       #PR       +/-##
==========================================
+ Coverage    89.91%    90.15%    +0.24%
==========================================
  Files          193       186        -7
  Lines        24825     23707     -1118
  Branches      8912      8528      -384
==========================================
+ Hits         22321     21373      -948
- Misses        2504      2334      -170
- Partials      1414      1362       -52

---

Generated by Codecov Action

[alexander-alderman-webb]

I'm good with this because having stuff implicitly gated by what you can import produces really unusable error messages. The message in _check_minimum_version is better by comparison.

The disadvantage is that we may specify a higher minimum support version than the integration technically supports, and then users could not use the code at their own risk anymore. But if we want to support that in the future it could probably be an opt-in 🤷

[sentrivana]

The disadvantage is that we may specify a higher minimum support version than the integration technically supports, and then users could not use the code at their own risk anymore. But if we want to support that in the future it could probably be an opt-in 🤷

That's true but considering how far back we go wrt supporting old versions I think this is ok. Even in the new major, when dropping support, I'm still keeping support for versions that are 5-6 years old unless there's a good reason not to.

If anyone is unhappy with the minimum boundary now being enforced, we can always change the behavior to just log a warning instead of disabling an integration. I wouldn't do that from the get go though, because I expect it'll lead to cryptic exceptions from random parts of the integration that are hard to debug for users.