Repository navigation
Date the 0.17.0 changelog entry for the tag day - #309
Merged
Merged
Conversation
The heading carried 2026-09-25, the day the section was first drafted. RELEASING.md requires it match the day the tag fires, and a release bakes the changelog into the published notes, so a stale date ships as the record of when the work landed. Nine days of drift this cycle, which is the second time on this release. Set at tag time rather than at version-bump time, because setting it any earlier is what produces the drift.
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
October 4 has passed, so the date must be refreshed to the actual tag date.
Review effort: Balanced
Findings: 1
Open (1)
What changed in this PR
Updates the 0.17.0 changelog heading to reflect the intended release date.
Changes:
- Changes the release date from September 25 to October 4, 2026.
| File | Description |
|---|---|
CHANGELOG.md |
Updates the 0.17.0 release date. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
chris-colinsky
added a commit
that referenced
this pull request
Oct 5, 2026
* Name the changelog timezone and all five version places Two gaps that each cost time during the v0.17.0 release. The changelog date requirement never named a timezone. A tag pushed in the evening US-Pacific carries a UTC timestamp on the next day, so for a few hours every night the two disagree and a reviewer reading UTC calls a correct heading stale, which is exactly what happened on #309. The convention the tags actually show is the maintainer's local day: v0.16.0 and v0.14.0 both have headings a day behind their UTC timestamps. v0.15.0 is the counter-example and it is simply wrong, a day behind its own local tag day. The version-bump item named three files. Five carry it. uv.lock locks the local package's own version and the bundled AGENTS.md stamps it into its header, and neither fails anything until an artifact is built, so both are easy to miss. They are generated, so the doc says to run the generator rather than hand-edit. Also records why the rc and real-release bumps cannot be one commit, in the place someone reads while doing it rather than in the comment at the top of the workflow. * Name what catches a missed version file The claim that nothing fails until the artifact is built was wrong three ways. A stale uv.lock fails the uv-lock pre-commit hook at commit time and uv sync --frozen in both CI and the release workflow; a stale bundled AGENTS.md fails test_agents_md_matches_generator_output. Saying no signal exists when three do is worse than saying nothing, because it teaches a maintainer not to look for the failure that will actually stop them. The two generated files are easy to miss because the checklist omitted them, not because they go undetected: you found out from a failing hook instead of from the doc, which is backwards for a checklist meant to prevent surprises. Naming each mechanism is the more useful form anyway, since it says which failure corresponds to which omission.
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.
One line. The 0.17.0 heading carried
2026-09-25, the day the section was first drafted; it now carries2026-10-04.RELEASING.md:41requires the date match the day the tag fires, and:132requires refreshing it if it drifted. A release bakes the changelog into the published notes, so a stale date ships as the record of when the work landed.Nine days of drift, and the second time on this release —
#301corrected it once already. Set at tag time rather than at version-bump time, because setting it earlier is what produces the drift.This has to merge and tag the same day or it is wrong again.
Release state behind it
Everything else is verified on
mainat4ae59c9:0.17.0in all five places0.118.2across all four sync pointspartial, consistent_tasks/, 0 proposalsMetadata-Version: 2.4, carriesconformance.toml+AGENTS.mdMetadata-Version: 2.4confirms thehatchling<1.30pin still holds; 1.30 emits 2.5, which the publish action's twine rejects.The three
partialstatuses (0064,0085,0124) ship labelled rather than held, with spec's sign-off in the release-review thread.0085and0124are folded into 0.18.0;0064closes when0020lands.After this
v0.17.0-rc1to TestPyPI, which is also the first exercise of thesetup-uvbump inrelease.yml— CI never runs that workflow, since it only fires on a tag. Thenv0.17.0if the rc installs clean.