Version 3.13

[tomchristie]

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:

• Issue a 3.13 release instead of a 3.12.5. Formally remove Python 3.5 and Django 3.0 support.
• Revert Make Field constructors keyword-only #7632, but include it in a later 3.13 release.
• Revert Make Field constructors keyword-only #7632, revise our decision on it (because is it really worth creating busy-work for existing users), and don't include it in a later 3.13 release.

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...

• Don't worry about it, just issue this as 3.12.5 as it currently stands.

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?

[carltongibson]

I would issue a 3.13, calling out the change (and the adjusted Python version support) in the release notes.

I always get complaints dropping even EOL versions in point releases. (Here I guess it's worth checking the python_requires value.)

[carltongibson]

Currently:

django-rest-framework/setup.py

Line 86 in 1cb3fa2

python_requires=">=3.5",

[tomchristie]

Just to make it clear: as it stands we're not EOL'ing anything.
Though if we got for a 3.13 then I think we probably should.

But sure, I'd be perfectly okay with that assessment.

See also #8286 as an option.

[carltongibson]

Formally remove Python 3.5 and Django 3.0 support.

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.)

[tomchristie]

@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.

[adamchainz]

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/

[tomchristie]

Ah thanks Adam! That was the one I was looking for. 😄

[adamchainz]

I would issue a 3.13, calling out the change (and the adjusted Python version support) in the release notes.

This sounds like the right path to me too. The keyword-only argument change will break some projects for sure.

[tomchristie]

Okey-dokesters. Two votes there is enough for me.
I can't quite see what a 3.13 version of the standard https://www.django-rest-framework.org/community/3.12-announcement/ announcement page would look like here.

"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?

[carltongibson]

Updates for latest versions.
Dropped EOL Versions.
Potential gotcha from #7632.

That's enough. (Numbers are cheap. :)

[tomchristie]

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.
It's a super big chunk of work, be great to get it wrapped in.

[pauloxnet]

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

[tomchristie]

@pauloxnet Absolutely. Good spot.

Adding it to the matrix in #8287 to see if it's currently running cleanly or not.

[tomchristie]

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.)

[pauloxnet]

Great 👍
I thought that there would be no compatibility problems, but surely Python 3.10 support had to be explicitly added.
Thanks 🙏

[pauloxnet]

@tomchristie I opened the PR #8288 for Python/Django compatibility

[tomchristie]

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.

[kevin-brown]

For what it's worth, I'm also +1 to cutting a 3.13 release with the keyword argument change in it. I'd love to also get the EOL changes included (since it's the perfect opportunity) but I can settle for those coming later. Nevermind, the current EOL changes are just right.

[tomchristie]

Okay, I think this is all we need really.
Anything else before we push on with it?

[carltongibson]

Is #8291 from @tim-mccurrach just worth looking at? 🤔

[tomchristie]

Seeeeemmmms like a good call, yup.

[carltongibson]

@tomchristie I didn't have a chance to think it through (yet) so I might ask @tim-mccurrach to explain it. 🧐

[tomchristie]

Right, done.

[carltongibson]

Thanks @tomchristie! 👍

[adamchainz]

[auvipy]

the core api deprecation pr's can be included if you want