Observed auditing rainlanguage/rain.solmem (rainlanguage/rain.solmem#87, [A25]).
The mechanism exists; nothing requires it
The published version is not chosen by the pipeline — it is [package].version read from the committed foundry.toml (in rain.solmem, now [external.package].version), and bump_patch only picks the next one. So a PR that breaks the public surface can already set 0.2.0 in the same PR and that is what publishes.
Nothing makes it. Evidence from rain.solmem, recorded on that issue:
0.1.11 removed LibStackPointer entirely — 185 lines, a whole public library — as a patch bump.0.1.8, 0.1.9 and 0.1.11 each added a new revert to consumeSentinelTuples, turning previously-accepted inputs into failures. All patch bumps.
Every one of those could have been expressed as a minor or a major. To a consumer taking ~0.1.x, they are indistinguishable from a doc-comment tweak.
Proposed fix
A check in the sol workflow that compares the public surface between the base and the head — the method-identifier set per library, the declared errors/selectors, and the set of library files under src/ — and fails when the surface changed while version moved only in the patch position. Derived from the compiled artifacts, so it needs no per-PR discipline and cannot drift.
Explicitly not a changelog
rain.solmem#139 added a hand-maintained CHANGELOG.md and was closed. A file that is only correct if every author remembers to update it is a second source of truth for facts the artifacts already carry. If release notes are wanted later, generate them at publish time from the tag range (git log --first-parent <prev-tag>..<tag> -- src/) rather than maintaining a file.
Refs rainlanguage/rain.solmem#87.
Observed auditing
rainlanguage/rain.solmem(rainlanguage/rain.solmem#87,[A25]).The mechanism exists; nothing requires it
The published version is not chosen by the pipeline — it is
[package].versionread from the committedfoundry.toml(inrain.solmem, now[external.package].version), andbump_patchonly picks the next one. So a PR that breaks the public surface can already set0.2.0in the same PR and that is what publishes.Nothing makes it. Evidence from
rain.solmem, recorded on that issue:0.1.11removedLibStackPointerentirely — 185 lines, a whole public library — as a patch bump.0.1.8,0.1.9and0.1.11each added a new revert toconsumeSentinelTuples, turning previously-accepted inputs into failures. All patch bumps.Every one of those could have been expressed as a minor or a major. To a consumer taking
~0.1.x, they are indistinguishable from a doc-comment tweak.Proposed fix
A check in the sol workflow that compares the public surface between the base and the head — the method-identifier set per library, the declared errors/selectors, and the set of library files under
src/— and fails when the surface changed whileversionmoved only in the patch position. Derived from the compiled artifacts, so it needs no per-PR discipline and cannot drift.Explicitly not a changelog
rain.solmem#139added a hand-maintainedCHANGELOG.mdand was closed. A file that is only correct if every author remembers to update it is a second source of truth for facts the artifacts already carry. If release notes are wanted later, generate them at publish time from the tag range (git log --first-parent <prev-tag>..<tag> -- src/) rather than maintaining a file.Refs rainlanguage/rain.solmem#87.