Conversation
github-actions
bot
requested review from
AlexWaygood,
MichaReiser,
carljm,
dcreager and
sharkdp
as code owners
AlexWaygood
added
ty
|
|
We should rework the github workflow so it no longer adds the "internal" label to these PRs. They lead to behaviour changes for ty users; we should include mentions of them in ty release notes. |
## Summary Ref: #18679 (comment) --------- Co-authored-by: Alex Waygood <[email protected]>
Can you say how should we highlight a change like this in the release notes? I'm not sure how useful it is to say that the typeshed version was bumped from commit A to B. |
It's a good question! Ideally I guess we'd list all the stdlib functions and classes that were changed, added or removed from the stubs, but I don't think there's an easy way to obtain that information. We could maybe link to a GitHub diff between the typeshed commit featured in our previous release and the typeshed commit in the new release -- that might be possible to automate? Pyright generally just says "Updated vendored typeshed stubs to the latest version" in its release notes. I agree that that isn't terribly informative for users. But they do at least get a link to the commit that shows the stubs being updated, which will allow them to check whether a change to the stdlib stubs that they care about was included in the latest pyright release. There are often users who find themselves unable to upgrade to the latest version of pyright or mypy due to regressions in typeshed, so I do think there are often users who will be grateful to know about typeshed changes! |
Yeah, I like this! We can start with this. I'm not sure about automation but we could update the release instructions to include this. |
|
And we always update this file when syncing vendored typeshed stubs, so it shouldn't be too hard to get a GitHub diff between the typeshed commit that was present in the previous release and the typeshed commit in the new release |
2 participants
Close and reopen this PR to trigger CI