Next release planning (1.13.2)

[intgr]

I'd like to make a new django-stubs release soonish.

I think this is a blocker:

• Revert "Used _ContextKeys for context like dicts" #1311

I don't know how to unlock mypy 0.991 support other than to disable testing with Django 3.2 and 2.2 (due to #1261). That's not ideal, but it is a step towards the new versioning policy we discussed in #1095 (comment) to only support the latest Django version.

• Update to mypy 0.991 for compatible-mypy & CI #1260

Nice to have PRs:

• Remove unintentional re-exports #1309
• Remove unintentional GeoDjango re-exports #1308
• Improve types of as_sql() and as_<engine>() methods #1315

Would this be version 1.13.2, 1.14.0 or go with #1095 (comment) and call it 4.1.0?

@sobolevn @adamchainz feedback welcome (and anyone else)

[ngnpope]

I'd like to see some resolution of #1276 as that is causing 150+ errors for me on a project using django-split-settings.

It'd be nice to get a bug fix release out that supports Django 3.2 still, so I'd say 1.13.2 or 1.14.0. I'm planning to see if we can add support for checking other versions like we can with sys.version_info to mypy. It'd be better to work towards that and keep support for more versions if we can.

[intgr]

I'd like to see some resolution of #1276 as that is causing 150+ errors for me on a project using django-split-settings.

Any takers to submit a PR for this?

I'd rather not delay the release for this, but I can do another release quickly once a solution for this materializes.

It'd be nice to get a bug fix release out that supports Django 3.2 still

FWIW there are no plans to break compatibility with Django 3.2 in a major way. Only when function signatures differ between Django versions, we prefer the newest function signatures (e.g. bulk_update() in #1114), and that is already true right now.

The reason I want to disable testing with Django 3.2 is issue #1261. I want to update django-stubs[compatible-mypy] and CI to use mypy 0.991. Thankfully so far this issue has only been observed in our CI. If it does happen to affect real word code, a work-around would be to downgrade to mypy 0.982 in that project. In any case I would like to hear if this affects any real codebases.

I'm planning to see if we can add support for checking other versions like we can with sys.version_info to mypy. It'd be better to work towards that and keep support for more versions if we can.

Sure, please post your thoughts and proposals in #1244.

[mschoettle]

Would be nice to include #1319 as well (assuming it will get approved) :)

[intgr]

The situation is this: I want to push this project forward and get the last month's worth of improvements released. But right now master branch IMO contains a significant regression. I don't want to make a release with this regression. Despite asking multiple times, so far nobody has explained to me, what those changes were hoping to achieve.

My agreement with sobolevn is that I also shouldn't merge nontrivial changes without approval from project members. And it makes sense, this shouldn't be a one-man show. But despite asking in a few places, nobody has provided any comments on #1311.

Besides this one, multiple other PRs I submitted did not get any feedback, although those aren't blockers.

I don't want to pester sobolevn any more than I already have, no doubt he has his plate full of plenty of other things. And that's not a long-term solution to these issues anyway.

TL;DR: This project needs additional members who have time and knowedge to review PRs, otherwise I'm blocked.

[ljodal]

I'd be happy to contribute, but I'm a bit unsure how much time I'd be able to set aside.

The company I work for is using a lot of Django, with multiple large projects using this plugin, so we've both uncovered a lot of things not covered by the test suite here and also feel pain when things don't work/are not supported. I can ask if I can set aside some time at work to contribute :)

For the specific PR in question here I'm also unsure what the goal of the initial PR was, but I predict a lot of errors in our codebases as well

[adamchainz]

I’ve been a bit absent since the birth of my baby boy a couple months ago. I’ll return to work Feb 6 with a client who uses django-stubs, so I’ll be able to spend more time on the projcet again then!

[intgr]

I can't personally add members to the project, but unless somebody objects, I'm going to accept PR approvals from community members as well.

Given that #1311 how has two endorsements from prior project contributors, I think I'm within my rights to merge it and go ahead with a release.

@ljodal Your help would very much be appreciated. If you find some time, you could start with taking a look at the remaining PRs I linked above.

And if someone else finds their contributions blocked by lack of review or anything, don't hesitate to ping me. The PR backlog here is long and in most cases it's unclear whether the original contributor is still around and motivated to go forward. But if motivation still exists, I would be happy help them back on track.

PS: Congratulations Adam 🎊

[intgr]

Version 1.13.2 was published: https://pypi.org/project/django-stubs/1.13.2/#history

No change in mypy version compatibility nor Django compatibility for now (context: #1260).

I will work on cleaning up release notes in a moment: https://github.com/typeddjango/django-stubs/releases/tag/1.13.2