Remove the Django upper bound

[dyve]

Summary

The <7.0 cap does not do what it looks like it does. It cannot make an install fail on a new Django major, because the resolver is free to backtrack to an older release of the package whose metadata never had a cap.

Verified against real PyPI metadata — asking for a Django the latest release excludes:

$ uv pip compile  ("django-bootstrap4", "django<5.2")
django==5.1.15
django-bootstrap4==26.1     ← not an error. an old release.

On Django 7.0 day, pip install django-bootstrap4 "Django>=7" resolves to 25.3 (django>=4.2, no cap) — old, untested code missing every 26.x fix. That is worse than installing the current release untested, where breakage surfaces in code that can be fixed and shipped the same day.

Capping the current release cannot close a door that already-published metadata left open. The cap buys nothing and costs resolution quality.

The django-version: main job in the CI matrix is the actual early warning: it breaks while the next major is still in development, when there is still time to release.

Documented in MAINTAINING.md so it does not drift back — this split was drift, not intent: three of the five packages never had a cap.

Test plan

• just lint passes
• just build passes end to end
• Wheel metadata now reads Requires-Dist: django>=5.2
• Verified the resolver behaviour above against live PyPI metadata

Companion PRs

• Remove the Django upper bound django-bootstrap4#881 — the other capped package
• Note in MAINTAINING.md why the Django dependency carries no upper bound django-bootstrap3#1142, Note in MAINTAINING.md why the Django dependency carries no upper bound django-bootstrap5#864, Note in MAINTAINING.md why the Django dependency carries no upper bound django-icons#651 — note only, already uncapped

Note

Both this and #675 add a ## Unreleased entry, and #675 also edits MAINTAINING.md. Whichever merges second will need a trivial rebase.