Consider loosening Django pin

[jacobtylerwalls]

I've set a monthly calendar reminder to check for Django security patches, which usually come out the first Monday of the month. If we loosened the upper bound on Django to include micro releases, projects wouldn't need to wait for us to update the pin and then eventually issue a patch release.

I also think we should consider loosening the upper bound on major versions of Django, now that we run the Arches test suite with DeprecationWarnings enabled. (If you run tests with DeprecationWarnings, you can still jump from LTS to LTS as we do without missing any "news" about breaking changes.) Projects should be able to use new features in Django 5.0 if they wish without waiting for us to enforce it as the floor for the whole ecosystem.

cc/ @chiatt

[chiatt]

I'm definitely in favor of loosening the upper bound on micro releases. We really should't have to worry about delivering a micro release of Arches just to pass along a Django patch. For major Django versions, I don't completely object to loosening the cap, but I'm a bit hesitant. My concern is that a new version of Django might come out shortly before an Arches release that we haven't really put through its paces.

[jacobtylerwalls]

Good point, we should only raise the cap near the beginning of an arches release cycle to give us the full period to test with it.

[chiatt]

That sounds like a good plan

[jacobtylerwalls]

Closed in #10688