What version of django-stubs should I use with Django 4.2 LTS?

[allanlewis]

My project uses Django 4.2 as that's the LTS; we don't plan to upgrade until 5.2 LTS is out. Given the table in the readme, which version of django-stubs should I use? I'm currently on 4.2.7, should I upgrade to 5?

One reason I'd like to upgrade is because I'm otherwise restricted to Mypy 1.7.x, which is now several minor versions behind the latest.

[sobolevn]

We have https://github.com/typeddjango/django-stubs?tab=readme-ov-file#version-compatibility which states that you should use 4.2.x

[intgr]

It's a tradeoff. For a project under active development, I personally would recommend upgrading to django-stubs 5.0.0 even if you use an older Django version. But be aware of the caveats below.

We still regularly fix issues and increase typing precision of features that Django has supported for a long time. Even as a Django 4.2 user, you would benefit from those improvements.

"Partial support" for older Django versions

According to our "Version compatibility" table, Django 4.1 and 4.2 remain with "partial support" by django-stubs 5.0.0. What partial support means in practice is:

• We won't remove any APIs from stubs that are still supported by Django 4.1/4.2, even if Django 5.0 removed those APIs.
• Any new APIs, parameters, etc added in Django 5.0 will of course will be added to stubs. So just because django-stubs contains some symbol, you can't be sure your older Django version necessarily supports it.
• In the very rare case where the same symbol has differing behavior between 4.1/4.2 and 5.0, stubs will reflect the behavior of Django 5.0. For example, a function may exist in both Django versions, but its return value have different type. This happens rarely, since Django goes through lots of effort to retain backwards compatibility.

(Of course mistakes can happen, please let us know if these are not upheld. And in general I would be interested to hear abou your experence)

Supported mypy version

I'd like to upgrade is because I'm otherwise restricted to Mypy 1.7.x, which is now several minor versions behind the latest.

Many years ago, mypy compatibility was finnicky because mypy regularly made backwards-incompatible changes to the plugin API. That's why the compatible-mypy extra was introduced.

More recently, mypy has been fairly stable. IMO mypy compatibility is more of a suggestion. I regularly violate the mypy version constraint in my own projects, I usually upgrade to newest mypy when it comes out. But at times I've also been a few versions behind (when there were bugs in mypy that affected me). I don't think I ever experienced any issues because of incompatible mypy version.

Of course there are no guarantees. Just do a full mypy run in CI, and don't merge the mypy update if there are obvious issues.

[allanlewis]

Thanks for the comprehensive response - much appreciated 🙏

If you violate that constraint in your own projects, I'll do the same 😄