django-rest-framework
django-rest-framework copied to clipboard
encode
Release notes for 3.15
Reviewing #8794.
Starting point, I've reviewed the release notes, and cleaned up items that shouldn't be included...
- Docs changes should not be part of our release notes.
- Project workflow changes should not be part of our release notes.
- Test changes should not be part of our release notes.
Our release notes should reflect changes to the released package version. So... behavioural changes that users may need to be aware of.
Project documentation, workflow, and testing isn't part of that and shouldn't be part of our release notes.
Valid candidates...
- https://github.com/encode/django-rest-framework/pull/9157
- https://github.com/encode/django-rest-framework/pull/9133
- https://github.com/encode/django-rest-framework/pull/9208 maybe?
Anything else that really oughta make this release?
may be this one #9180
The latest stable of Django is 5.0, so I recommend to not worry about fixing Django 5.1+ for DRF 3.15. There is enough goodies in it already 😄 Maybe create a patch release shortly after that includes it?
I was going to merge all commits and add Tom and Auvipy to the co-authored in the log and it turns out it's another branch in the encode repo... :D heheh so, no editing from here...
I agree with @tomchristie that those are valid candidates - though they would also require minor adjustments in the RN.
These seem innocuous (no changes to the RN and small fixes) that won't hurt including:
- https://github.com/encode/django-rest-framework/pull/9232
- https://github.com/encode/django-rest-framework/pull/9231
- https://github.com/encode/django-rest-framework/pull/9198
Other nice-to-haves that seem inobtrusive and sooner the better to get downstream would be:
- https://github.com/encode/django-rest-framework/pull/9213
- https://github.com/encode/django-rest-framework/pull/9087
To me, the most important for this release would be setting the stack up to Django 5 and Python 3.12 so it is aligned with upstream of the requirements. Once this is done, the rest can go into minor releases
I've noticed that 3.14.0 doesn't explicitly support Django 4.2. Can that be added to 3.15.0?
I've noticed that 3.14.0 doesn't explicitly support Django 4.2. Can that be added to 3.15.0?
Can you point out where? All I found is https://github.com/encode/django-rest-framework/pull/9233/commits/c77b0e92ce939087186584930279ad86c208e0e7 which already contains it
See also... https://github.com/encode/django-rest-framework/discussions/9270
Would it make sense to upload a release candidate for 3.15 to PyPI so that folks could test it more easily? Or is it too much work for the maintainers?
Interesting idea thanks, not sure?
You can currently install from master...
pip install git+https://github.com/encode/django-rest-framework.git
That's fair enough. I was half expecting that answer, to be honest 😄
For folks who, like me, might not have git installed in their production image, GitHub produces a tarball of the repo:
pip install https://github.com/encode/django-rest-framework/archive/master.zip
With Poetry:
- djangorestframework = "3.14.0"
+ djangorestframework = { url = "https://github.com/encode/django-rest-framework/archive/master.zip" }
(if you end up using it, you probably want to replace master by the latest commit sha)
@encode/maintainers - Are there any other blockers for this, or can we fix a release date?
(Hmmm, also I can see our tests are passing, but the pre-commit is failing - I'm unclear on what needs resolving there, anyone?)
I think some spelling mistakes are breaking the pre-commit(codespell) action, I've commented them out.
@TGoddessana Could you issue those as +/- suggestions, so we can merge them?
Anything else blocking us from merging this?
Not sure if a blocker, but you might want to update that sentence with -at least- an updated date:
At the Internet, on January 12th, 2024, with 135 commits 107 authors, we are happy to announce the release of Django REST framework 3.15.
you might want to update that
Okay, someone want to propose a release date and make a +/- suggestion?
This is the final step to release, right? If so, the sooner the better, but I think you'll want to review your release process and set your own time to release.
Okay, I'd suggest March 15th... perhaps someone could issue a +/- suggestion and we plan on making the release then?
Okay, I might have enough time to roll this release later today... (on schedule ☺️) unless there's any objections? Minor query from my perspective... are we okay with the supported range of Python & Django, or should we keep them more constrained?... (Example... We could bump up the formal support to Django 4.0 and Python 3.8 in our docs without actually changing anything else)
https://docs.djangoproject.com/en/stable/faq/install/#what-python-version-can-i-use-with-django still supports Django 3.2 (at least until next month).
However, I think we could safely drop support for Python < 3.8 (https://devguide.python.org/versions) because supporting five different versions of CPython is enough effort.
Perhaps release this as is and then in a few months create a release that drops Django v3.x and also Python < 3.8.
Okay, we're merged add ready to publish. The deploy to pypi will need to wait until monday now...
Thank you guys for pushing this out the door. Much appreciated!
Now that the pypi release is done, we should probably also craft a github release for 3.15.0.
