Next release planning (4.2.0)

[intgr]

The next django-stubs release is way overdue. Since our last release, mypy 1.2.0 and Django 4.2 have been released. compatible-mypy version is already upgraded (#1429), and we already have some improvements for Django 4.2 support -- although it's far from complete.

This also brings a scope increase to django-stubs-ext, it now offers a typehinted base class for Model Meta (#1375).

New version numbering scheme

As discussed previously in #1095 (comment) and few other places, we want to adopt a new version numbering scheme, similar to typeshed types-* packages, where first two digits indicate latest Django version, and the third digit version is just a sequential counter of django-stubs releases. So first release after Django 4.2 will be django-stubs 4.2.0, next 4.2.1 etc.

The downsides of this are:

• It could be considered incompatible with semver. In particular, while we try to minimize the impact, django-stubs-ext changes could have adverse effects on production code.
• We will lose the ability to communicate major or minor changes via the version number. But AFAIK we haven't really used that in the history of TypedDjango.

If someone has arguments against this version scheme change, now is the last opportunity to voice them.

This new scheme would apply to both django-stubs and django-stubs-ext (refs #1409). To avoid confusion, we should keep these version numbers in sync in the future (either we always release both, or if django-stubs-ext release is skipped, the next django-stubs-ext release can skip some numbers to catch up to django-stubs).

I want to re-iterate that this does not in any way change our policy for older Django versions. Type stubs have always tracked the latest Django version, but Django itself tends to be fairly backwards compatible. And we will continue running CI tests with older Django versions and make sure we don't break them in a big way.

Action items

• We should add CI testing with Django 4.2.
• Check if djangorestframework-stubs CI needs changing.
• Adding 4.2 to DJANGO_COMMIT_REFS in typecheck_tests.py. I'm afraid updating the ignore lists will be a significant amount of work. Perhaps it's not a release blocker.
• There are a few recent unreviewed pull requests, we should work through those.
• Document how to use django-stubs-ext TypedModelMeta.

Please let me know if I missed something.

[intgr]

A related question is, do we adopt a similar version scheme for djangorestframework-stubs? Following djangorestframework upstream it would become 3.14.0. I assume the answer is yes, but it hasn't really been explicitly mentioned.

[sobolevn]

I am not using drf for quite some time now, but I think that the similar scheme makes sense.

[karamanolev]

FWIW, I think the new version scheme is what it should be and what is used in most of the rest of the community.

[intgr]

• Reminder: After this release, we should drop Python 3.7 support fully (related: CI: Stop testing with Python 3.7 #1453).
• Also drop testing Django 4.0 which is EOL. But it will probably continue working.

[intgr]

django-stubs and django-stubs-ext 4.2.0 have been released!

• Release notes: https://github.com/typeddjango/django-stubs/releases/tag/4.2.0
• PyPI: https://pypi.org/project/django-stubs/4.2.0/#history
• PyPI: https://pypi.org/project/django-stubs-ext/4.2.0/#history

[intgr]

Due to a packaging issue, the new django_stubs_ext.db.models.TypedModelMeta feature was not included with this release (the db/ folder did not get included in release archives). This issue did not appear for me when I was testing with pip install -e (editable). Sorry!

It's not a big deal though, I will continue wrapping up this release, and defer TypedModelMeta to the next release which I'll do soon-ish.

[intgr]

I have completed editing the release notes: https://github.com/typeddjango/django-stubs/releases/tag/4.2.0

[sobolevn]

Congrats, @intgr! Great work! 🎉

[intgr]

Just to expand on this point:

This new scheme would apply to both django-stubs and django-stubs-ext. To avoid confusion, we should keep these version numbers in sync in the future (either we always release both, or if django-stubs-ext release is skipped, the next django-stubs-ext release can skip some numbers to catch up to django-stubs).

One of the reasons for this is that we don't need two separate git tags for django-stubs and django-stubs-ext, and thus also don't need to split up release notes. May seem like a minor detail, but it reduces the number of things I need to keep track of while making releases, I think it's a significant win.

[adamchainz]

Thank you once again @intgr. I'm going to roll this across my projects and will report any issues.

[adamchainz]

Upgraded my 14 open source projects using django-stubs, no issues, one # type: ignore could be removed. 👍

[jp-larose]

Stumbled on this trying to figure out why the example of TypedModelMeta wasn't working. I just installed django-stubs using pip (from pypi), and the db subpackage isn't there. Looks like you guys caught the packaging error, but might not have uploaded to pypi?

[bigfootjon]

@jp-larose check the comment above from @intgr

@intgr: can you do a 4.2.1 release to include this?

[jp-larose]

Oh... Ha! I missed the tail end of the comment where he said it would be deferred.

[intgr]

Yep, sorry! I was planning to do the next release quicker, but have been postponing it. I'll try to get the release out in the next few days.

[intgr]

Unpinning this issue, opened the next one:

• Next release planning (4.2.1) #1510