Release schedule

[aleksanb]

Can we release the newest main to PyPI?

It's possible to install main via a github url directly in pip, but that's somewhat cumbersome and i've had issues specifying the correct version of django-stubs-ext when installing that way.

[PIG208]

https://github.com/typeddjango/django-stubs/archive/74e31c7562c7b983fbef832b13629ee8c13636ff.zip#egg=django-stubs-ext==0.6.0+git&subdirectory=django_stubs_ext
https://github.com/typeddjango/django-stubs/archive/74e31c7562c7b983fbef832b13629ee8c13636ff.zip#egg=django-stub==1.12.0+git

works for me. Replace the commit hash with the revision you need.

[aleksanb]

works for me. Replace the commit hash with the revision you need.

great! I was missing the subdirectory part of the url.

[adamchainz]

You can use Pip's updated VCS support to pull with Git rather than zip files. This should be quicker than zip files now, afaiu, e.g.:

django-stubs @ git+https://github.com/typeddjango/django-stubs.git@354a892ecc45ef92e3200a10920e124d60f279a5
django-stubs-ext @ git+https://github.com/typeddjango/django-stubs.git@354a892ecc45ef92e3200a10920e124d60f279a5#subdirectory=django_stubs_ext

[christianbundy]

We haven't made a release with support yet, but until then you can install from Git (#1095 (comment)).

It probably goes without saying, but lots of folks use package mirrors that require a release to pypi, and can't safely install directly from this github repo. I'm happy to help push releases more regularly, but unfortunately the Git workarounds don't work for everyone.

[adamchainz]

Understood. I've just started as a maintainer, I'm hoping I can help make relaeses more regular.

It's also possible to copy the stubs into your project, I blogged about doing so recently.

[Thorbenl]

Is there any plans on making this compatible with 4.1? :( Usually didnt take so long to make it work.

[orsinium]

Despite having a way to install from the source, proper releases are way better. Why would people use them otherwise, right? And it would be great to have estimations on how often releases are expected. No pressure :) I tried to look at the release history, but there is no clear pattern. I personally release my projects after each MR merged (because the whole release is a one-liner in bash), but my projects are way smaller.

[flaeppe]

I think there was something merged considered a release blocker #1163 (comment)

Don't think it's resolved yet, I might be wrong though

[intgr]

The last release of django-stubs was on June 17, four and a half months ago. Since then there have been 131 commits to the master branch, but all this work is useless for users until it has been released.

If I'm spending my time contributing to these projects, it's usually because I have encountered an issue. If the contributions were to be released within a week, I may be able to delay changes in my own project and avoid implementing any workarounds on my side. If it's a month, I almost certainly need to implement workaround on my end and clean them up after the stubs release. However, if it takes more than quarter a year, I will already have forgotten what issues there were and what workarounds have been implemented. Meanwhile these workarounds often result in worse type safety and increased maintenance burden.

Personally I would prefer a weekly release if there have been significant changes on the master branch, perhaps smaller things don't warrant quite a weekly release. But that's just a dream at this point. :)

@sobolevn as the only currently active maintainer:

• If there are blockers preventing a release, please communicate these blockers very explicitly so they can be easily found. Maybe a certain label for issues? So motivated users can work on clearing them, or even discuss reverting the problematic change.
• If you just don't have the time and motivation to be doing releases, maybe the task of making releases can be delegated to another volunteer?
• Any other reasons for delays that I may be missing?

[sobolevn]

@intgr do you want to join our team? :)

Drop me a line at mail @ sobolevn.me if you do.

[ljodal]

Just adding my few cents here:

• If there are blockers preventing a release, please communicate these blockers very explicitly so they can be easily found. Maybe a certain label for issues? So motivated users can work on clearing them, or even discuss reverting the problematic change.

I think from my point of view, getting #1173 merged is a blocker from using the main branch currently. These are real errors in the type stubs that don't match up with Django behavior. We can use ignore comments to suppress these errors, but it would be great to not have to do that.

As noted about there's also some issues related to #1163 (comment) that might cause a lot of confusion, so I think it at least warrants a section in the FAQ of the project. I'd be happy to contribute that.

Other than that I'm not aware of any issues with the current main branch in our fairly large Django project.

[sobolevn]

New version is released: https://github.com/typeddjango/django-stubs/releases/tag/1.13.0

[adamchainz]

Thanks for the release @sobolevn !

I think from my point of view, getting #1173 merged is a blocker from using the main branch currently. These are real errors in the type stubs that don't match up with Django behavior. We can use ignore comments to suppress these errors, but it would be great to not have to do that.

I’ve saw your PR and I wanted to review it thoroughly, since I also recently touched the session types.

Unfortunately, a lot of stubs are still misaligned with Django, and until we get the coverage up and strictness. I think using ignore comments in select places (or a git install) is going to be a fact of life for a while yet. But contributions will help us solve this!

(Edit: At least with warn_unused_ignores you can learn when a new version means you no longer need certain ignore comments.)

[michael-k]

New version is released: https://github.com/typeddjango/django-stubs/releases/tag/1.13.0

Thank you for the release. Can you please update https://github.com/typeddjango/django-stubs#version-compatibility accordingly?

[sobolevn]

I have a proposal about releases.

Versioning

Right now we have this version compat table https://github.com/typeddjango/django-stubs#version-compatibility which is very complex and not very accurate.

We also have a problem that we don't have any support for different django versions.

Proposed solution:

1. Change version scheme to match django minor releases. So, if django has 4.1.x release, we will release 4.1.y versions. Matching MAJOR.MINOR will indicate what django versions are supported.
2. This means that we will only support one major django version at a time. Yes, I know that a lot of people are using different django version. But, I don't think that it is bad: typeshed does this as well. There are not enough maintainers / funding to have all django versions supported. We can occasionally do manual releases for older version with critical bugs fixed (like new mypy bugs, etc)
3. This will allow us to automate releases. We can release new versions each week: if there are any new commits

@adamchainz @intgr @mkurnikov what do you think?

[mkurnikov]

Sounds great to me.

I had an idea of code preprocessing at the time, some kind of #ifdef from C, transforming pyi files for different versions of Django. But I don't think it's gonna be implemented any time soon, i don't participate in django-stubs anymore, and other resources are pretty limited.

[intgr]

This means that we will only support one major django version at a time.

👍 I feel the tension between supporting multiple Django versions and having accurate type hints. I tend to keep my projects on the latest Django version, so that sounds fine to me.

I wouldn't preclude supporting multiple Django versions. But for that to work, there needs to be some person willing to put in the work to develop and maintain it:

• We could keep separate branches alive for supporting older Django releases.
• We could add some sort of if django_version < (4, 1): guards as proposed in a few places (e.g. Fix regression in '.bulk_update()' annotations for Django 3.2 #1114 (comment))

I have no interest in working on these personally and it seems nobody else in the TypedDjango team has either.

[sobolevn]

We could add some sort of if django_version < (4, 1): guards as proposed in a few places

This tends to be very problematic. Mypy needs to learn about this: the same way it check sys.version_info. So, I need to push this idea to others in mypy core team. And right now I don't have the time for this :(

[intgr]

That's fine. Just to clarify: I agree with dropping support for older Django releases for now.

I'm open to re-introducing backwards compatibility if someone comes up with a proposal and is willing to develop a clean solution for it.

[ljodal]

Would it make sense to maintain separate branches for older versions, so if someone's willing to fix something in an older version they can submit a PR against that (possibly just backports of the latest branch)? I realize that this adds a bit of extra work on the maintainers, but I assume that these PRs should be fairly simple to merge, and then maybe the same release automation could be applied to the legacy branches?

[sobolevn]

Yes, sure: we can do separate branches with no promises of supporting them or ever merging back into the main branch.

[adamchainz]

I’d also be happy just supporting the latest version of Django, for now.

@ngnpope did suggest he’d found a possible path to versioned hints using literal integer types: #1160 (comment) . But it remains to be seen if that is feasible.

[adamchainz]

I opened an issue to continue the discussion about conditional types based on Django version: #1244

[djbrown]

hello guys :) when will 1.13.1 be released?
I have the same problem as #1235 which was fixed a month ago in #1239
but no new version since then :0

[intgr]

There's an open PR #1241. I am not entirely sure why it stalled. There is a crash with mypy 0.991 when used with Django 3.2 (#1261), but IMO it shouldn't be a blocker for the release (if we don't bump compatible-mypy version).

[intgr]

@djbrown django-stubs 1.13.1 released now: https://github.com/typeddjango/django-stubs/releases/tag/1.13.1

[intgr]

Just to explain why this wasn't implemented yet: I was considering changing the version scheme a few months ago (#1316), but I felt some apprehensive vibes in a few comments about dropping compatibility with older Django versions (e.g. #1316 (comment) and also somewhere else, can't remember). So I didn't feel like pursuing that, and later I just forgot.