Repository navigation
ci: Vendor Update bumps a beta on a regeneration that changes only comments #1674
Description
Problem. cron-vendor.yml bumps the version and pushes whenever tj-actions/verify-changed-files@v17 reports any changed file, after pcapkit-vendor and isort. A regeneration that changes only comments or docstrings therefore cuts a beta and starts a Create Release run. That happened twice today: b10 and b11 changed only reference formatting (#1664, fixed by #1673).
Measured (prototype in #1673's notes): comparing each changed pcapkit/const/**/*.py with HEAD by AST, docstrings stripped, classifies b9, b10 and b11 as comment-only and still flags b8's member rename. But b9 was a genuine upstream change, a draft becoming RFC 10049, that lives only in comments.
Decision needed — when a regeneration is comment-only:
- commit it without bumping the version, so the next real change carries it into a release;
- drop it, and commit nothing;
- keep today's behaviour, and bump on any change.
Recommended: (1). Documentation-only upstream updates such as b9's still reach main, and only a code change cuts a beta.
Activity
JarryShaw commentedon Oct 13, 2026
Take (1) but if it's too complex to implement, I'd keep today's behaviour - comments are generated as docs so they can be useful for new releases.
JarryShaw commentedon Oct 13, 2026
Recorded: option (1). A regeneration whose only changes are comments or docstrings gets committed without a version bump, so it reaches
mainwithout cutting a beta. A worker has it. The plan is a stdlib AST guard incron-vendor.yml, which compares each changedpcapkit/constmodule withHEADwith docstrings stripped, and bumps only when some module's code differs.If the guard turns out too complex or fragile in practice, I'll come back here before falling back to today's behaviour.
ci(vendor): commit a comment-only regeneration without bumping the ve…
Updated vendor documentation without a version bump
docs(repo): second whole-repo pass over repo-level files (#1103) (#1804)