Next release planning (4.2.5)

[flaeppe]

TODO:

• Add better support for ManyToManyField's through model #1719
• Add plugin support for users = ManyToManyField(settings.AUTH_USER_MODEL) Resolve any settings.AUTH_USER_MODEL used as to in relation #1746

#1719 introduces plugin support for ManyToManyField but is lacking support for passing AUTH_USER_MODEL as to= arg e.g.:

users = ManyToManyField(settings.AUTH_USER_MODEL)

Which we suspect is a normal use case and should support in any next release.

---

Please comment on this issue if there's anything else you know should, or want to be included.

[flaeppe]

And for anyone feeling adventurous, please try out HEAD on your project(s) and report back here if you run in to anything you think is a new issue. Perhaps we can then resolve it before pushing out a release.

[intgr]

Now that mypy 1.6.0 is out, we should consider making a release with the compatible-mypy bump. I can do the release.

I'd consider this a blocker, since it's a regression and we already have a fix PR:

• Add missing _default_manager symbol to generated through model #1745

[intgr]

I'm releasing djangorestframework-stubs too, any takers to review this for the release:

• Allow None for Pagination.template attribute djangorestframework-stubs#482

[flaeppe]

It'd be nice if we could also include #1767 in the next release

[intgr]

I want to move forward with:

• Make mypy a soft dependency #1628

Making no changes quite yet, but I propose mentioning in 4.2.5 release notes that the next next version (4.2.6) will remove hard mypy dependency. Something like:

(outdated text)

django-stubs is taking steps to improve experience with other type checkers besides mypy. Next version (4.2.6) will remove explicit mypy dependency. If you are currently using mypy, please add an explicit dev dependency on mypy to your project, or depend on django-stubs with the compatble-mypy extra, e.g. django-stubs[compatible-mypy].
Note: this is not a guarantee that other type checkers will be fully supported, pull requests for improvements are welcome. See #1628 for details.

If you have comments on this, please discuss in #1628.

[intgr]

Should I cut the release or wait for the cached_property work to be completed?

• Reuse functools.cached_property definition instead of defining our own #1771
• Update @property attributes to @cached_property part 1 #1761
• Update @property attributes to @cached_property part 2 #1768
• Update Expression classes output_field to @cached_property or ClassVar and improve type #1769

[flaeppe]

We could always push another release if we want to. If you feel that one is due

[sobolevn]

I think property stuff can wait, really.