Skip to content

chore: release 0.4.2 - #25

Closed
dmccoystephenson wants to merge 2 commits into
mainfrom
release/0.4.2
Closed

dmccoystephenson wants to merge 2 commits into
mainfrom
release/0.4.2

Conversation

@dmccoystephenson

Copy link
Copy Markdown
Member

The version in pyproject.toml and trace_client/trace_client.py is set to 0.4.2 for the stable release.

Opened by release automation. Nothing is published by this PR: once it is merged, the merge commit is run through the library's own tests, a save-compatibility check against 0.4.1 and every consumer's test suite, and only a commit that passes is tagged 0.4.2. See python-release-gates.


drafted by Claude on behalf of Daniel Stephenson

Version bump for the stable release; the release itself is published only after
the candidate passes the release gates.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@dmccoystephenson

Copy link
Copy Markdown
Member Author

Review of the 0.4.2 release PR (head d43c380). Two independent problems keep it from merging. It is left open for the owner, because version bumps and pyproject.toml are owner-only release decisions.

1. The version bump is incomplete, so the test suite fails on the PR head. The version string appears in five places. The release automation changed only two of them:

  • pyproject.toml:7 — bumped to 0.4.2
  • trace_client/trace_client.py:22 (__version__) — bumped to 0.4.2
  • trace_client/trace_client.py:1 — module header still reads trace-client 0.4.1
  • trace_client/__init__.py:1 — module header still reads trace-client 0.4.1
  • tests/test_trace_client.py:296 and :301 — test_user_agent_names_the_client_version still asserts 0.4.1

Running python3 -m unittest on the PR head with Python 3.8.10 locally gives Ran 67 tests ... FAILED (failures=2), and both failures come from that test (AssertionError: '0.4.1' != '0.4.2'). The same 67 tests pass at main. The headers matter beyond the tests: they are how vendored copies of trace_client.py identify their version. This may be worth fixing in python-release-gates too, so that future release PRs bump all five places.

2. CI cannot go green here at the moment, for reasons unrelated to this diff. test (3.8) failed at setup-python with The version '3.8' with architecture 'x64' was not found for Ubuntu 26.04 (ubuntu-latest has moved to 26.04), and fail-fast cancelled 3.10 and 3.12. This affects main and every PR equally. It is tracked in #26.

Rubric:

  • Scope: PASS — only the two version-bearing files are touched
  • Version agreement: FAIL — 3 of the 5 places still say 0.4.1 (see above)
  • Tests: FAIL — 2 failures locally on the PR head, both from the unbumped test assertions
  • CI: FAIL — structurally red (runner image), carries no signal for this diff; tracked in CI: test (3.8) can no longer install Python 3.8 on ubuntu-latest (Ubuntu 26.04), so every Build run fails #26
  • Stdlib-only / never-raises / log level / exports: PASS — no code changed
  • Java parity: no Java-visible behavior changed (only the version string in the User-Agent)
  • Do-not-auto-merge: matches pyproject.toml and the version string, so the owner merges this

Also deferred this cycle: #16 (version tag exceeding MAX_TAGS). It was not picked up because a PR was already open, and its fix changes which tags go on the wire, so it needs a matching decision in trace-client-java.

This review was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).


drafted by Claude on behalf of Daniel Stephenson

@dmccoystephenson

Copy link
Copy Markdown
Member Author

Closed as a duplicate of #27, which releases the same 0.4.2 from a newer base.

drafted by Claude on behalf of Daniel Stephenson

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant