chore(release): renumber unreleased 0.77.1 to 0.78.0, log #546 - #550
Merged
Conversation
v0.77.1 was merged but never tagged, and the next release will be 0.78.0 bundling several PRs -- so the changelog key and pyproject version are renumbered rather than leaving an entry for a version that will not exist. More importantly, #549 landed with no changelog entry at all, matching how #530/#531 landed before their release PR. That is the failure mode that left 0.67.0-0.70.1 unpublished and undocumented, so the #546 fix is written up now rather than at tag time. Also clears the two `redundant-cast` warnings my #549 tests introduced. Deleting the casts turned them into `unresolved-attribute` ERRORS -- `TextIOWrapper.buffer` is declared as `_WrappedBuffer`, which has no `getvalue` -- so the fix is to stop reaching through `.buffer` at all: a small frozen `Cp1250Stdout` holds the `BytesIO` directly. That also gives the streaming tests in the other class access to the same helper, which they did not have.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bookkeeping ahead of the 0.78.0 release. No behaviour change.
Why
1. #546 has no changelog entry at all. #549 merged without one, matching how #530 /
#531 landed before their release PR bundled them. That is exactly the failure mode that
left 0.67.0–0.70.1 merged-but-unpublished and undocumented, so the entry is written now
while the change is fresh rather than reconstructed at tag time.
2.
0.77.1will never exist. It is merged intomain(pyproject.tomland achangelog key) but was never tagged, and the next release is 0.78.0 bundling several PRs.
Leaving the key would ship 0.78.0 with its fixes filed under a version nobody can install.
So:
0.77.1→0.78.0inpyproject.tomlandchangelog.py, the(since v0.77.1)tagsin
gotchas.mdretargeted,make version-syncrun, and the #546 entry added above the#528 one.
Also: two
redundant-castwarnings I introduced in #549tyflaggedcast(io.BytesIO, stream.buffer)in the new tests. Deleting the casts turnedthe warnings into
unresolved-attributeerrors —TextIOWrapper.bufferis declaredas
_WrappedBuffer, which has nogetvalue— so removing them would have been adowngrade from a non-blocking warning to a blocking one.
The actual fix is to stop reaching through
.buffer: a small frozenCp1250Stdoutholdsthe
BytesIOdirectly alongside the text wrapper. That also gives the streaming testsaccess to the helper, which lived in the other test class and was unreachable from them —
they had been duplicating the wrapper construction.
Preferred over returning a 2-tuple, which CONTRIBUTING's "Code Quality Patterns" rules out
for semantically distinct values (the same rule Devin cited on #543).
tyis now down to the 3 pre-existing warnings onmain, none from this code.Checks
make checkgreen — ruff, format, ty, skill, version, command-sync, changelog, errorcodes, and 4744 tests.
Note for the release
Windows users on ≤0.77.0 should install 0.78.0 with the recovery command rather than
letting auto-update make the jump — the update to the fixed version is still performed
by the old, unsafe updater on their current install. From 0.78.0 onward auto-update is
safe. Both #528 and #546 reporters have been told; worth repeating in the release notes.