Support Django 5.0 - Githubissues

HypothesisWorks / hypothesis

Hypothesis is a powerful, flexible, and easy to use library for property-based testing.

https://hypothesis.works

Other

7.53k stars 586 forks source link

Support Django 5.0 #4026

Closed jams2 closed 2 months ago

jams2 commented 3 months ago

This PR adds support for Django 5.0, and drops support for Django < 4.2 as 4.2 is the oldest currently supported version.

Upgrade considerations:

from 5.0 support for pytz in Django is dropped — use of pytz was deprecated in 4.0 in favour of Python's built-in zoneinfo; and
a transitional setting, FORMS_URLFIELD_ASSUME_HTTPS is added until 6.0, when the default for URLField.assume_scheme will become "https".

Django 5.0 adds a new field, GeneratedField. As values of this field are managed by the database back-end, I updated from_model to ignore instances of GeneratedField.

I labelled this as a minor release, as I don't know whether dropping support for older versions of a dependency is considered a breaking change to the public API of Hypothesis.

Zac-HD commented 3 months ago

I labelled this as a minor release, as I don't know whether dropping support for older versions of a dependency is considered a breaking change to the public API of Hypothesis.

Minor release is exactly right; we don't consider it a breaking change because upstream made the EOL decision, but it's not a patch release either 🙂

jams2 commented 3 months ago

as a stretch goal it'd be nice to check automatically that we're testing against all and only supported Django versions in our update-deps cronjob - we already do for CPython...

Happy to take a look at that @Zac-HD, but I'm not sure what it should look like. Would that be adding a task to upgrade_requirements, similar to update_python_versions?

Zac-HD commented 2 months ago

Would that be adding a task to upgrade_requirements, similar to update_python_versions?

Yep - I think we'd want to write to a literal in the __main__.py file, so the upgrade task will succeed in doing at least part of the job, and then we can have a test (like the Python one) that the relevant substring is in our main.yml file that defines GitHub Actions. The result should be that the next weekly update PR shows up with failing CI and a clear note about what to do!

...and since that's a test-only change, I suggest that we make it as a separate PR; I should get this one unblocked and merged tomorrow.