Repository navigation
Tie the version to the PR number and stop hardcoding it - #40
Merged
Merged
Conversation
__version__ had been "0.1.0" since the initial commit — unchanged through 38 merged PRs — so it described nothing. It is now 0.2.<PR>, where the patch component is the number of the pull request that introduced the change, making any build traceable to one PR and its diff. Because a PR number does not exist until the PR is opened, the bump happens inside the PR via tools/set_version.py (which can infer the number from gh), and a new `version` job in release.yml fails the PR when __version__ and the PR number disagree. That job is what stops the scheme rotting the way the old constant did. The User-Agent strings were the real damage from hardcoding: client.py carried "glean-code/0.1" in two places and auth/oauth.py in a third, all stale from the moment the version moved. They now derive from __version__ through a single client.USER_AGENT, and the doctor probe reports the version too. A test asserts no string anywhere in glean_code/ hardcodes a version. It reads string tokens via tokenize rather than raw lines, so prose in a comment that mentions an old value does not trip it — which it did on the first attempt, flagging the comment explaining the very problem. Tests: 1,173 -> 1,177. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
What
__version__has been0.1.0since the initial commit — unchanged through 38 merged PRs — so it described nothing. This sets it to0.2.<PR>, where the patch component is the number of the PR that introduced the change.0.2.40for this one.Why this shape
A build now maps to exactly one PR and its diff, which is the traceability a date-grouped changelog was standing in for. It also sidesteps the judgment call about 1.0: the
0.2series makes no stability promise while the VS Code extension and IDE work churn the client API.How it cannot rot
A PR number does not exist until the PR is open, so the bump happens inside the PR:
A new
versionjob inrelease.ymlfails the PR when__version__and the PR number disagree. That job is the thing the old constant lacked.The damage hardcoding already did
client.pycarried"glean-code/0.1"in two places andauth/oauth.pyin a third — every one stale from the moment the version moved, and every request has been sending them for 38 PRs. They now derive from__version__through a singleclient.USER_AGENT, and the/doctorprobe reports the version too.A test asserts that no string in
glean_code/hardcodes a version. It reads string tokens viatokenizerather than raw lines, so prose in a comment mentioning an old value doesn't trip it — which it did on my first attempt, flagging the comment that explains the very problem.Tests
1,173 → 1,177. Verified the guard still fails when a hardcoded UA is reintroduced.
🤖 Generated with Claude Code