1.12/1.13 Release Tracking Issue

[hauntsaninja]

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?

[cdce8p]

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.1 release with the binaries once the new Python release is out.

[JukkaL]

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.

Just to clarify, would you like a new release now (before 3.13.0) or afterwards with compiled binaries for 3.13?

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]

For the later, we'd probably need to wait for cibuildwheel to be updated.

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]

However, that requires no code changes, one can upload additional wheels to PyPI at any time.

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.

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.

Is the issue the busywork caused by such a release, or is there something else?

[mr-c]

However, that requires no code changes, one can upload additional wheels to PyPI at any time.

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.

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.

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.

Is the issue the busywork caused by such a release, or is there something else?

The busywork would be annoying, yes :-)

[JukkaL]

Hmm.. I don't see why it would be confusing?

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]

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]

Just did one more typeshed sync before the release branch is cut:

• Sync typeshed #17833

[JukkaL]

I've been testing the latest master, and I've found one release blocker so far:

• Wrong type inferred when "not in" narrowing Any  #17841

[JukkaL]

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]

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.

@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]

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.