Version 3.13 #8285
Version 3.13 #8285
Conversation
|
Currently: django-rest-framework/setup.py Line 86 in 1cb3fa2 |
|
Just to make it clear: as it stands we're not EOL'ing anything. But sure, I'd be perfectly okay with that assessment. See also #8286 as an option. |
Also Django 3.1 is EOL as of Tuesday, so I'd be inclined to drop that too. (I know it feels quick, but there's no reason for folks to be on 3.x but not 3.2.) |
|
@carltongibson Is there a one-stop page on the Django docs that show which versions are currently under security-support? I looked around to try to figure out which versions we ought to be supporting, but I didn't get a clear enough view of it. |
There's the timeline graph on https://www.djangoproject.com/download/ |
|
Ah thanks Adam! That was the one I was looking for. 😄 |
This sounds like the right path to me too. The keyword-only argument change will break some projects for sure. |
|
Okey-dokesters. Two votes there is enough for me. "Hey folks we have Django 4.0 support! Yays. Please continue as you were." I mean, probably that's actually ookkkkaaayyyy. They can't all be ritzy snazzsters of a release right? |
|
Updates for latest versions. That's enough. (Numbers are cheap. :) |
|
This... #7411 might be worth pulling in for 3.13 too right? I'm not sure how best to review it, but we might as well get on with it, and tease out any issues that need resolving. |
|
IMO since Django 3.2.9+ and 4.0 both support Python 3.10 it would be worth adding support for Python 3.10 in DRF before releasing version 3.13 |
|
@pauloxnet Absolutely. Good spot. Adding it to the matrix in #8287 to see if it's currently running cleanly or not. |
|
We're good. 😎 (I mean, that's what you'd hope for right - python bumps are mostly backwards compat apart from the occasional deprecation along the way. We more typically need to track deprecations in Django than deprecations in the Python stdlib.) |
|
Great 👍 |
|
@tomchristie I opened the PR #8288 for Python/Django compatibility |
|
Okay I've reviewed the bootstrap update, and I don't think that'll make the cut, at least for this version. #7411 I'll prob have a look into wrapping this up into a 3.13 release on Monday. |
|
For what it's worth, I'm also +1 to cutting a 3.13 release with the keyword argument change in it. |
|
Okay, I think this is all we need really. |
|
Is #8291 from @tim-mccurrach just worth looking at? 🤔 |
|
Seeeeemmmms like a good call, yup. |
|
@tomchristie I didn't have a chance to think it through (yet) so I might ask @tim-mccurrach to explain it. 🧐 |
|
Right, done. |
|
Thanks @tomchristie! 👍 |
|
|
|
the core api deprecation pr's can be included if you want |
* Version 3.12.5 * Version 3.13 * Version 3.13
Okay, so we ought to get a new minor point release out, in order to handle Django 4.0 comparability.
I've based the release notes here on the changes from https://github.com/encode/django-rest-framework/commits/master and only including actual package changes. Most of our commit history at the moment is docs + tooling tweaks, which aren't relevant to the release notes.
I'm slightly concerned about #7632 here - there's potential for us introducing breakage here. Options here include:
Actually we really only need to make a decision between (1) and (2 or 3). In order words, we can revert #7632, and make a decision on it for 3.13 some other time.
There's also another option...
But that's probably not in out user interests - I'd guess that we're bound to have enough folks not using keyword arguments on their fields, that we'll add some unexpected breakages in a minor point release, which probably ain't what we want.
Thoughts @encode/django-rest-framework maintainers / anyone?