Tags from patchrail

v0.7.6

2026-07-22T19:28:57Z

v0.7.5

2026-07-22T13:04:08Z

release: 0.7.5 (#398)

Cut 0.7.5 from main. 0.7.4 (2026-07-22) capped the confidence of a verdict held
up by tool invocations alone, but it shipped that cap while the reports still
printed `Root cause: <class>` / `Confidence: 0.3` in the same shape as a 0.95.
The number dropped, the message didn't — so a maintainer who runs
`pip install patchrail` today still reads "root cause" under a verdict PatchRail
itself does not trust, and goes off to fix a file that is fine.

b66fb4c fixed the message in both human-facing renderers and has been sitting on
main, unreleased, since it merged. This release is that one fix: a report below
LOW_CONFIDENCE_THRESHOLD (0.35) now says in prose that it is a hint rather than a
proven cause, that its signals only show a tool ran, and where to look next.
Presentation only — class, confidence, exit code and the `--format json` payload
the GitHub Action consumes are untouched, and a high-confidence report is
byte-identical to 0.7.4.

Version bumped in the five places that spell it out (pyproject, __init__, README
quickstart, uv.lock, the benchmark's release-status line) and CHANGELOG's
Unreleased section dated.

Co-authored-by: PabloCodes7 <hello@getpatchrail.com>

v0.7.4

2026-07-21T23:01:09Z

release: 0.7.4 (#396)

Cut 0.7.4 from main. The last release, 0.7.3 (2026-07-16), predates ten
false-positive fixes that are sitting on main and not on PyPI: an installed
pytest read as a failing test run (#376), a passing test's title read as a
secrets failure (#380), a PHPUnit assertion read as a Composer failure (#378),
Flutter's cached Gradle Wrapper (#382), Cabal's dependency resolution read as
Maven (#383), Crystal and dune's make targets read as C/C++ (#384, #385), a
parenthesized 504 (#391), mypy in a pixi manifest (#390), an unset TERM read as
a missing secret (#392), a warning-only yarn install and a recovered checkout
(#393), and a verdict held up by invocations alone reporting diagnosis-level
confidence (#395). Every one of those is a wrong answer a maintainer gets today
from pip install patchrail.

Version bumped in the four places that spell it out (pyproject, __init__,
README quickstart, uv.lock), CHANGELOG's Unreleased section dated, and the
real-world benchmark's release-status paragraph corrected: it no longer claims
six fixes are unreleased.

Co-authored-by: PabloCodes7 <hello@getpatchrail.com>

v0.7.3

2026-07-16T02:34:18Z

release: 0.7.3 (#369)

Co-authored-by: PabloCodes7 <hello@getpatchrail.com>

v0.7.2

2026-07-15T08:03:13Z

release: 0.7.2 (#362)

Co-authored-by: PabloCodes7 <hello@getpatchrail.com>

v0.7.1

2026-07-14T22:05:54Z

release: 0.7.1 (#356)

Co-authored-by: PabloCodes7 <PabloCodes7@users.noreply.github.com>

v0.7.0 — nine fixes for one mistake

2026-07-14T20:33:47Z

release: 0.7.0 — nine fixes for one mistake (#351)

Since 0.6.1, nine fixes landed on main and PyPI has none of them. All nine are
the same mistake: a line that NAMES a tool read as a line proving that tool
FAILED. An install listing, an echoed script, a suppressible CMake warning, a
cache cleaning up after a job that was already dead, a test quoting a compiler
back at itself.

The CHANGELOG was missing an entry for one of them (#336, the echoed step
source), so it is written here from a measurement, not from the commit message:
0.6.1 reads ruff's Rust panic as `python_test_failure` at 0.53, carried by
`FAILED .*::` matching the text `Failed to install CodSpeed CLI::` inside an
error branch belonging to a download that succeeded. main reports
`rust_test_failure`. The new docs/real-world-benchmark.md gets an Added entry.

Version bumped in all four places test_version_consistency ties together
(pyproject, __version__, the README quickstart line, uv.lock) -- the README
line is the one that broke the 0.6.1 release CI.

898 passed on Python 3.12, ruff/format/mypy clean, benchmark 221/221 with 0
failures.

Co-authored-by: PabloCodes7 <pablocodes7@users.noreply.github.com>

v0.6.1

2026-07-14T13:24:41Z

release: 0.6.1 (#331)

* release: 0.6.1

Ships the #329 fix: an annotation that announces a success is no
longer handed back as somewhere to start. The Action pins patchrail
>=0.6.0,<0.7.0 and surfaces runner_errors as PR annotations, so its users pick
this up on the next run without changing anything.

* release: point the README quickstart at 0.6.1

The version-consistency test guards that the quickstart advertises the version
that actually ships; it caught the bump leaving the README behind.

---------

Co-authored-by: PabloCodes7 <pablocodes7@users.noreply.github.com>

v0.6.0 — an unknown log that explains itself, and no more invented diagnoses

2026-07-14T12:34:42Z

release: 0.6.0 — stop shipping a classifier that misreads a real log (#…

…328)

Three commits have been on main since 0.5.0 went out this morning and none of them
reaches anyone: PyPI still serves 0.5.0, which tells a Go repository its Node lockfile
is out of date. That came out of piping real failing runs from public repositories
through the one-liner in the README, the way a first-time user meets this tool. Of
eight new ecosystems, three were confidently wrong: oven-sh/bun diagnosed from a
prettier file list and a `lockfile/` directory in a path; istio/istio told it had a
Java build failure and a Node install failure, both read out of a single-line
Dependabot JSON blob; withastro/astro matched on `--no-frozen-lockfile`, the flag that
permits the change it was complaining about.

Minor, not patch: an `unknown` verdict now carries a `runner_errors` field, which is
new surface. The classifier changes are behaviour changes by design — a wrong
diagnosis becomes `unknown`, which is the honest answer for a log we do not recognize —
and no fixture changes class or confidence (221 fixtures, top-1 1.0). Real logs that
already classified are untouched.

The Action's default range stays `>=0.5.0,<0.6.0` and is bumped separately, once this
is live on PyPI and its suite has been run against a 0.6.0 wheel — the same order 0.5.0
followed, and the reason the cap exists.

Co-authored-by: PabloCodes7 <hello@getpatchrail.com>

v0.5.0 — real logs, real causes

2026-07-14T10:32:28Z

release: 0.5.0 — get five merged accuracy fixes to the people install…

…ing today (#322)

Five fixes have been sitting on main since 0.4.0 this morning and none of them
reaches a user: PyPI still serves 0.4.0, which reads a tool the job merely named
as the cause of death. That is not a hypothetical — running `ci explain` over real
failing runs from public repositories put it at three of nine (httpx, prefect,
home-assistant) and then, on a second sweep across non-Python ecosystems, three of
seventeen (kafka, moby, opencv), where a `GRADLE_HOME=` line in a Windows
environment table was enough to diagnose a Java build failure in a job that never
compiled anything. A first-time user's first log is a real log, not a fixture.

Minor, not patch: `patchrail schema ci-classes` is new surface. The classifier
fixes are behaviour changes by design — a diagnosis that was wrong becomes right —
but no fixture changes classification or confidence (221 fixtures, top-1 1.0).

The GitHub Action's default range stays `<0.5.0` on purpose and is bumped
separately, once this is live on PyPI: 0.4.0 moved the `ci classes` JSON from v1 to
v2 in a minor bump and the break reached the Action silently, so the cap now earns
its keep. Verified before tagging: the Action's suite passes against a 0.5.0 wheel
and the payload it consumes is still `patchrail.ci_classes.v2`.