Repository navigation
1.12/1.13 Release Tracking Issue #17815
Description
It would be nice to make a release. It's been about two months since 1.11. We have a couple nice changes in there and it'd be great to release a version of mypyc that should work on Python 3.13.0 (which should be released in about a week).
Do any of the Dropbox folk have time to drive a release?
Activity
cdce8p commentedon Sep 24, 2024
Just to clarify, would you like a new release now (before 3.13.0) or afterwards with compiled binaries for 3.13? For the later, we'd probably need to wait for cibuildwheel to be updated.
Of course it'd also be possible to do a
1.12.1release with the binaries once the new Python release is out.JukkaL commentedon Sep 24, 2024
I was already planning to start the release process this week :-)
I was waiting for Python 3.12 type parameter syntax to be officially supported and enabled by default. Mypyc support for 3.13 and compiled binaries for 3.13 would a great addition!
I'm planning to cut the release branch by the end of the week.
It looks like the planned release date for 3.13.0 is Oct 1. 1.12 won't be released before Oct 1, so it's possible that we could include compiled binaries for 3.13. If cibuildwheel doesn't get updated soon enough, we can make a 1.12.1 release afterwards.
mr-c commentedon Sep 24, 2024
I was curious about this and found mypyc/mypy_mypyc-wheels#82 which is failing against 5c38427 from September 16th.
Testing Python 3.13 mypy wheels won't work until Python 3.13.0 final (with the recently merged python/cpython#124273) is released, and cibuildwheel is updated to use it.
However, that requires no code changes, one can upload additional wheels to PyPI at any time.
As a downstream packager of mypy for Debian and the recipient of many Dependabot notifications, I would request that there isn't a "1.12.1" mypy release without code changes.
So hopefully mypy 1.12.0 can be released with Python3.13 wheels, or those wheels can be built & uploaded later without needing a "no-change" 1.12.1 mypy release.
JukkaL commentedon Sep 24, 2024
I guess we can upload new wheels, but only if they become available within a few days of the mypy release -- otherwise it could be confusing.
Is the issue the busywork caused by such a release, or is there something else?
mr-c commentedon Sep 24, 2024
Hmm.. I don't see why it would be confusing? I understand that your automated script might not be setup to do that as of today.
The busywork would be annoying, yes :-)
JukkaL commentedon Sep 24, 2024
There is a small risk that the initial compiled binary for 3.13 would contain bugs specific to the compiled version, so anybody that has been using mypy pinned to 1.12.0 on Python 3.13 would suddenly start experiencing new issues.
hauntsaninja commentedon Sep 25, 2024
As of #17812 we know for sure that the test suite passes with a mypyc-compiled mypy on latest Python 3.13
I feel good about the odds that our 3.13 build stack is ready for us by the time we release 1.12. And thank you to cdce8p for keeping cibuildwheel up-to-date / handling the cibuildwheel regression
cdce8p commentedon Sep 26, 2024
Just did one more typeshed sync before the release branch is cut:
JukkaL commentedon Sep 27, 2024
I've been testing the latest master, and I've found one release blocker so far:
JukkaL commentedon Sep 27, 2024
This release will fix many false negatives in an internal codebase I'm using for testing. This is great, but it slows down the testing process, since I want to check that any new errors actually were false negatives.
cdce8p commentedon Sep 27, 2024
@JukkaL Not sure if it might you help but a while ago I started to uploading compiled dev builds to PyPI. They are stable enough that we even use these in day-to-day testing and CI. It has helped immensely to limit the changeset from version to version and made detecting actual regressions easier.
https://pypi.org/project/mypy-dev/
https://github.com/cdce8p/mypy-dev
JukkaL commentedon Sep 27, 2024
Our internal mypy runner scripts can download wheels from mypy_mypyc-wheels, so testing them is already fairly easy (but it's still manual). I think I'll spot check new errors generated by PRs known to fix false negatives, and will carefully scrutinize new errors caused by other PRs only.
JukkaL commentedon Sep 27, 2024
I'm looking into fixing (at least partially) this performance issue before cutting the release branch:
34 remaining items
hauntsaninja commentedon Oct 18, 2024
I cherrypicked the existing patches to the 1.12 branch and opened #17995 for the typeshed revert on 1.12 (reverted on mypy master in #17988)
hauntsaninja commentedon Oct 19, 2024
I'll cut a 1.12.1 and a 1.13.0 in the next few days!
mr-c commentedon Oct 19, 2024
I'm very glad for 1.12.1 to be released with fixes for the regressions, but on behalf of the maintainers of the over 250,000 repositories that use mypy, please don't release 1.13 right away.
https://github.com/python/mypy/network/dependents
Users who want the bleeding edge can instead depend on https://github.com/cdce8p/mypy-dev / https://pypi.org/project/mypy-dev/
As a compromise, you can make a pre-release of 1.13.0 to PyPI and on GitHub. That will be ignored by Dependabot (and perhaps other auto-updaters), but still be available for installing by those who wish to opt-in.
(None of the above is said with my Debian hat on. If a pre-release of 1.13 is made I will update the Debian package to use it)
hauntsaninja commentedon Oct 19, 2024
I will be releasing a 1.13. I got into contributing to mypy because mypy makes my life better, it feels silly to be sitting on unreleased patches that make mypy 2.2x faster in the environment I use mypy in most often, and probably 10%-15% faster for many users.
Like I said above, 1.13 will just be cherry picks on top of 1.12.1 and not include type checking related changes, so hopefully it should be fairly smooth! — likely smoother than 1.12.0 -> 1.12.1 which will affect type checking. If you have a specific concern, we can figure out if there's a way to mitigate it. I'm not sure a pre-release makes sense if we don't have an actual release corresponding to that pre-release / it's unclear to me what problem it solves.
[-]1.12 Release Tracking Issue[/-][+]1.12/1.13 Release Tracking Issue[/+]hauntsaninja commentedon Oct 20, 2024
1.12.1 is out.
https://github.com/python/mypy/tree/release-1.13 is the branch for 1.13. #18000 is changelog PR. I'm planning on release 1.13 on Monday (pending any discussion in this thread)
DanielNoord commentedon Oct 20, 2024
As somebody involved in updating dependencies within my company and some of those packages, please keep releasing like this.
It is silly to recommend work arounds to update to new versions as it only increases the amount of work needed to do dependency updates (for example, when do I switch back of the main repository). Besides, releasing often means that releases are smaller and investigating regressions is easier.
I understand that for distribution maintainers the situation is slightly different as they don't have Dependabot and friends, but packages that depend on
mypyand have some sort of automatic updates set up (which many platforms offer free of charge to OS packages) would likely benefit from frequent smaller releases than one big breaking release.Due to the importance of
mypyin daily developer workflows (we're all waiting on CI) I actually find myself eagerly checking release tracking issues as almost every release has something that unblocks one of my colleagues. Having less frequent releases would only hurt me and those dependent on the updates I do.JukkaL commentedon Oct 21, 2024
The most recent commits (including 5c4d2db) in the v1.13.0 branch don't have wheels, so there is no easy way to test the compiled wheels. I'd like to run it against a big internal codebase.
hauntsaninja commentedon Oct 21, 2024
I cherry picked the changelog update to the branch, so bc0386b is latest on release-1.13. Wheel build is now running here: https://github.com/mypyc/mypy_mypyc-wheels/actions/runs/11447856493 (edit: looks like build was successful)
I'll wait to hear back from you before making the 1.13 release.
JukkaL commentedon Oct 22, 2024
I did some quick testing, and the 1.13.0 branch worked without issues, and it was about 6% faster type checking a big codebase at work, compared to 1.12. This is a nice improvement, considering the codebase doesn't have the bottlenecks that were the focus of the recent perf improvements!
hauntsaninja commentedon Oct 22, 2024
1.13 is released!
hauntsaninja commentedon Oct 24, 2024
After a week of calm, a few more regressions got reported in the last 24 hours:
typing.overloadandParamSpec#18027If we do another patch release, we could cherry pick:
JukkaL commentedon Oct 28, 2024
Published 1.13 blog post (slightly delayed): https://mypy-lang.blogspot.com/2024/10/mypy-113-released.html
svalentin commentedon Nov 19, 2024
Closing this as 1.13 has been out for a while now without big complaints here.
I've opened the issue for 1.14: #18169