The kompile-core version bump convention was ambiguous when main declared 0.0.122 but a closed

Reported (UTC): 2026-07-16 09:19

The kompile-core version bump convention was ambiguous when main declared 0.0.122 but a closed pull request had already published kompile manager 0.0.123 and an open pull request reserved 0.0.124. Initially bumping an extracted replacement change to 0.0.123 caused kotlin.build remote CI to download the already-published manager-0.0.123.jar from kotlin.directory, so CI was not testing the new branch artifact and two consecutive runs orphaned at the identical 58848-byte initialization point with 0 of 100 tests. Maven metadata confirmed 0.0.123 as the published latest even though main remained 0.0.122. After changing the branch release to the next unused and unreserved version 0.0.125, rerunning all seven affected files successfully, and force-pushing, the new remote run progressed from 0 to 10 of 100 tests instead of wedging. Impact: a plausible main-plus-one bump silently reused stale closed-branch bytecode, wasted multiple CI runs, and could have validated excluded behavior from that closed branch. Workaround: before selecting a release version, check kotlin.directory Maven metadata for published versions and inspect open pull requests for reserved versions, then choose the next unused value. Durable fix: document and automate this check in the kompile-core release convention or CI, and reject a branch whose RELEASE_VERSION already exists in the repository.

Production verification — 2026-07-17

Status: STILL EXISTS. Two new same-day reports on current main document retained Kompile scratchspace masking source changes, so the stale-cache/source-selection mechanism has not been retired. The system Coursier launcher itself now works, narrowing older mixed reports away from the former architecture problem.

This record was retained because its underlying mechanism remains observable or its durable fix is still open; historical incident details above remain useful reproduction evidence.