Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 1.10.0 release #886

Merged
merged 3 commits into from
Mar 26, 2022
Merged

Version 1.10.0 release #886

merged 3 commits into from
Mar 26, 2022

Conversation

sobolevn
Copy link
Member

No description provided.

@sobolevn sobolevn merged commit 3c58270 into master Mar 26, 2022
andersk added a commit to andersk/django-stubs that referenced this pull request Jun 3, 2022
Due to a bug in mypy 0.940 (typeddjango#870), we made two changes in typeddjango#871:

• pinned mypy==0.931 in requirements.txt (for running our tests);
• bounded mypy<0.940 in setup.py (for downstream users).

After the mypy bug was quickly fixed upstream in 0.941, our setup.py
bound has been repeatedly raised but not removed (typeddjango#886, typeddjango#939, typeddjango#973).
The only changes in those commits have been to the precise wording of
error messages expected in our tests.  Those wording changes don’t
impact compatibility for downstream users, so it should be safe to go
back to allowing them to upgrade mypy independently.

Signed-off-by: Anders Kaseorg <[email protected]>
andersk added a commit to andersk/django-stubs that referenced this pull request Jun 3, 2022
Due to a bug in mypy 0.940 (typeddjango#870), we made two changes in typeddjango#871:

• pinned mypy==0.931 in requirements.txt (for running our tests);
• bounded mypy<0.940 in setup.py (for downstream users).

After the mypy bug was quickly fixed upstream in 0.941, our setup.py
bound has been repeatedly raised but not removed (typeddjango#886, typeddjango#939, typeddjango#973).
The only changes in those commits have been to the precise wording of
error messages expected in our tests.  Those wording changes don’t
impact compatibility for downstream users, so it should be safe to go
back to allowing them to upgrade mypy independently.

Since mypy doesn’t yet guarantee backwards compatibility in the plugin
API (although in practice it has rarely been an issue), add a
django-stubs[compatible-mypy] extra for users who prefer a known-good
version of mypy even if it’s a little out of date.

Signed-off-by: Anders Kaseorg <[email protected]>
andersk added a commit to andersk/django-stubs that referenced this pull request Jun 3, 2022
Due to a bug in mypy 0.940 (typeddjango#870), we made two changes in typeddjango#871:

• pinned mypy==0.931 in requirements.txt (for running our tests);
• bounded mypy<0.940 in setup.py (for downstream users).

After the mypy bug was quickly fixed upstream in 0.941, our setup.py
bound has been repeatedly raised but not removed (typeddjango#886, typeddjango#939, typeddjango#973).
The only changes in those commits have been to the precise wording of
error messages expected in our tests.  Those wording changes don’t
impact compatibility for downstream users, so it should be safe to go
back to allowing them to upgrade mypy independently.

Since mypy doesn’t yet guarantee backwards compatibility in the plugin
API (although in practice it has rarely been an issue), add a
django-stubs[compatible-mypy] extra for users who prefer a known-good
version of mypy even if it’s a little out of date.

Signed-off-by: Anders Kaseorg <[email protected]>
sobolevn added a commit that referenced this pull request Jun 4, 2022
* Move mypy version upper bound to a [compatible-mypy] extra

Due to a bug in mypy 0.940 (#870), we made two changes in #871:

• pinned mypy==0.931 in requirements.txt (for running our tests);
• bounded mypy<0.940 in setup.py (for downstream users).

After the mypy bug was quickly fixed upstream in 0.941, our setup.py
bound has been repeatedly raised but not removed (#886, #939, #973).
The only changes in those commits have been to the precise wording of
error messages expected in our tests.  Those wording changes don’t
impact compatibility for downstream users, so it should be safe to go
back to allowing them to upgrade mypy independently.

Since mypy doesn’t yet guarantee backwards compatibility in the plugin
API (although in practice it has rarely been an issue), add a
django-stubs[compatible-mypy] extra for users who prefer a known-good
version of mypy even if it’s a little out of date.

Signed-off-by: Anders Kaseorg <[email protected]>

* Update setup.py

Co-authored-by: Nikita Sobolev <[email protected]>
PIG208 pushed a commit to PIG208/django-stubs that referenced this pull request Jun 13, 2022
…go#979)

* Move mypy version upper bound to a [compatible-mypy] extra

Due to a bug in mypy 0.940 (typeddjango#870), we made two changes in typeddjango#871:

• pinned mypy==0.931 in requirements.txt (for running our tests);
• bounded mypy<0.940 in setup.py (for downstream users).

After the mypy bug was quickly fixed upstream in 0.941, our setup.py
bound has been repeatedly raised but not removed (typeddjango#886, typeddjango#939, typeddjango#973).
The only changes in those commits have been to the precise wording of
error messages expected in our tests.  Those wording changes don’t
impact compatibility for downstream users, so it should be safe to go
back to allowing them to upgrade mypy independently.

Since mypy doesn’t yet guarantee backwards compatibility in the plugin
API (although in practice it has rarely been an issue), add a
django-stubs[compatible-mypy] extra for users who prefer a known-good
version of mypy even if it’s a little out of date.

Signed-off-by: Anders Kaseorg <[email protected]>

* Update setup.py

Co-authored-by: Nikita Sobolev <[email protected]>
@sobolevn sobolevn deleted the version-1-10-0 branch June 17, 2022 14:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant