Add a binary-compatibility check (MiMa) — commons prototype - #38
Closed
halotukozak wants to merge 4 commits into
Closed
Add a binary-compatibility check (MiMa) — commons prototype#38halotukozak wants to merge 4 commits into
halotukozak wants to merge 4 commits into
Conversation
There's no MiMa plugin for scala-cli, so .mima/bin-compat-check.scala calls
mima-core's API directly (Scala 2.13 script, same pattern as
.scoverage/report.sc) to compare the last released JAR against a freshly
built --library JAR, both directions.
.github/workflows/mima.yml wires it in. Report-only for now: pre-1.0, and
this is a prototype — incompatibilities surface as a warning + job summary,
they don't fail the build. Standalone workflow (not synced from
halotukozak-com/.github) until it's proven.
TASTy-MiMa isn't included: tasty-mima 1.4.1 can't read Scala 3.9.0 TASTy
yet ("TASTy signature has wrong version").
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019awuXm5QZgXajLw3PvGo1s
On pull_request runs, add the needs-major label when MiMa finds a binary break (creating the label if it doesn't exist yet), and remove it again on a later push once the PR is compatible again. Still non-blocking — this is the "small" reporting mechanism instead of failing the build. No needs-minor yet (would signal a source/TASTy-only break): TASTy-MiMa can't read Scala 3.9's TASTy format yet, so there's no signal to drive it from. Add it once tasty-mima catches up. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019awuXm5QZgXajLw3PvGo1s
Forward compatibility (new API vs the old release) always shows "problems" whenever anything is added — that's expected for any minor bump, not a signal of anything wrong. Only backward (can code compiled against the release still link against the new build) is the actual SemVer contract a same-major release makes, so only that should gate needs-major. Forward is still printed for context. Also: temporarily rename wontHappen -> wontHappenTmpRenameForMimaTest to verify the needs-major label actually gets applied on a real backward break (will revert once confirmed). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019awuXm5QZgXajLw3PvGo1s
github-actions
Bot
added
the
needs-major
Confirmed: needs-major got applied on the backward-incompatible rename. Reverting wontHappen back to its real name now that the label mechanism is verified in both directions. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019awuXm5QZgXajLw3PvGo1s
github-actions
Bot
removed
the
needs-major
This was referenced Aug 28, 2026
scala-steward
pushed a commit
to scala-steward/alpaca
that referenced
this pull request
Aug 29, 2026
Mirrors the setup validated on halotukozak-com/commons#38 (which alpaca doesn't get automatically — no scala-cli, no `com.halotukozak::` sync group applies here). Report-only: manages a needs-major PR label on a real *backward* binary break, never fails the build. Differences from the scala-cli version: - New JAR comes from `./mill show jvm.jar` instead of `scala-cli package --library`. Mill 1.x's `show` wraps paths as `ref:v0:<hash>:<path>` / `qref:v1:<hash>:<path>` — stripped with sed. - Shared classpath comes from `./mill show jvm.compileClasspath` (alpaca's actual deps: regex, made, commons) plus scala3-library from the old-artifact resolution (scala-cli's coursier shim), since Mill's compileClasspath doesn't list the Scala standard library separately. - Baseline org is `io.github.halotukozak`, not `com.halotukozak`: alpaca's publish.yml actually publishes there (confirmed from Sonatype logs — "Successfully published io.github.halotukozak.alpaca_3-0.1.4"), even though the README says `com.halotukozak::alpaca`. `com.halotukozak:alpaca_3` doesn't exist on Maven Central at all. That mismatch is a separate issue worth fixing on its own. The check itself (.mima/bin-compat-check.scala, mima-core's API) is identical to the scala-cli version — no alpaca-specific logic needed there. Verified locally: v0.1.4 -> HEAD correctly reports 192 backward problems (the internal.parser package has been substantially reworked since). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019awuXm5QZgXajLw3PvGo1s
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.
First small step toward MiMa + TASTy-MiMa across the libraries.
What
.mima/bin-compat-check.scala— there's no MiMa plugin for scala-cli, so this callscom.typesafe::mima-core's API directly (Scala 2.13 script, same pattern as.scoverage/report.sc). Compares the last released JAR against a freshly built--libraryJAR, both backward and forward..github/workflows/mima.yml— resolves the baseline from the latestv*tag, builds the current library JAR, runs the check.Report-only, via a label
Pre-1.0 (SemVer allows breaking minors) and this is a prototype, so it never fails the build. Instead, on a PR it manages a
needs-majorlabel: added when MiMa finds a binary incompatibility, removed again on a later push once it's compatible. Visible and trackable without blocking merges.No
needs-minoryet (would flag a source/TASTy-only break, milder than binary): see below.TASTy-MiMa not included yet
tasty-mima 1.4.1(latest) can't read Scala 3.9.0 TASTy —TastyFormatException: TASTy signature has wrong version. Tried overriding itstasty-querydependency to 1.9.0 (released yesterday, which does support 3.9.0 TASTy) — the format now reads, but tasty-mima's analyzer isn't compatible with the newer tasty-query API and throws internal errors on every symbol. Needs an upstream tasty-mima release built against tasty-query 1.9.x. Will wire upneeds-minoronce that lands.Verified locally: passes for
0.1.2 → HEAD, and correctly flags the0.1.0 → 0.1.2diff (newTailRecTraversable,deepRecursiveFunction, signature changes).🤖 Generated with Claude Code