[deps] Update django-filter requirement from <25.0,>=23.5 to >=23.5,<26.0

[dependabot]

Updates the requirements on django-filter to permit the latest version.

Changelog

Sourced from django-filter's changelog.

Version 25.1 (2025-02-14)

• Removed the in-built API schema generation methods, which have been deprecated since v23.2.

  You should use drf-spectacular <https://drf-spectacular.readthedocs.io/en/latest/>_ for generating OpenAPI schemas with DRF.

• Dropped support for EOL Python 3.8.

• Added testing against Python 3.13.

• Added official support for Django 5.2.

Version 24.3 (2024-08-02)

• Adds official support for Django 5.1.

• Allow using dictionaries for grouped choices on Django 5.0+.

  Thanks to Sævar Öfjörð Magnússon.

• Adds unknown_field_behavior FilterSet option to allowing warning and ignore behaviours for unknown field types during FilterSet generation.

  Thanks to Loes.

Version 24.2 (2024-03-27)

• Fixed a regression in v23.4 where callable choices were incorrectly evaluated at filter instantiation, on Django versions prior to 5.0.

  Thanks to Craig de Stigter for the report and reproduce.

Version 24.1 (2024-03-08)

• Updated supported Python and Django versions, and resolved upcoming Django deprecations.

  Required versions are now at least Python 3.8 and Django 4.2.

  Thanks to Michael Manganiello.

• Allowed passing a FilterSet class to the filterset_factory().

  Thanks to Birger Schacht.

... (truncated)

Commits

• 27dd672 Updated Change notes for 25.1 release.
• 2ea3817 Added Trove classifier for Django 5.2.
• 4d2306c Replaced hardcoded pks in tests (#1703)
• fbf5a76 Update tox after Django 5.2 alpha release. (#1700)
• 1e76d68 Use QueryDict for data default. (#1691)
• e709e5d Add testing against Python 3.13.
• ccde000 Dropped support for EOL Python 3.8.
• 2a644e1 Removed deprecated schema generation methods from DRF backend. (#1698)
• 2494df9 fix typo in filterset.txt (#1695)
• 3656174 Translated using Weblate (Czech) (#1687)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[adamchainz]

It would be great to remove the upper version bounds altogether, per this classic post (TLDR). The upper bound here has blocked my Django 5.2 testing, as I need to upgrade django-filter to a compatible version.

[nemesifier]

It would be great to remove the upper version bounds altogether, per this classic post (TLDR). The upper bound here has blocked my Django 5.2 testing, as I need to upgrade django-filter to a compatible version.

Due to the limited availability of maintainers, we prefer to maintain strict bounds and let dependabot update the upper bounds and run CI tests as new releases come out. It may not provide the same flexibility, but it's sane and ok for us to maintain.

[auvipy]

It would be great to remove the upper version bounds altogether, per this classic post (TLDR). The upper bound here has blocked my Django 5.2 testing, as I need to upgrade django-filter to a compatible version.

we can manually update/upgrade them as well

[ulgens]

@nemesifier Is it possible to create a new release with this update?

[nemesifier]

@ulgens we need to backport (cherry-pick -x) the minor changes / bugfixes and dependency upgrades to the 1.1 branch, prepare the change log and publish the tag. If you want to help with any of this please send a PR to the 1.1 branch.

[ulgens]

@nemesifier I created another PR to update DRF's upper bound: #334 When it's merged, I can handle backporting both updates to 1.1

[ulgens]

@nemesifier It seems that 1.1 was finalized, and there is a new 1.2 branch, up-to-date with the latest master. Do we still need to backport these version updates?

[nemesifier]

@ulgens 1.2 branch automatically tracks master until 1.2 will be released.
The 1.1 branch is for publishing 1.1.x bugfix releases.
Yes we need to back port, if you add a commit which updates the change log I can publish a tag and it will be automatically released.