Three modules are Kotlin Multiplatform now, and apiCheck tracks one .api file per module: the JVM
one. Everything the validator is relied on for is therefore a statement about a single target.
That is a smaller guarantee than it reads as. A change to a commonMain declaration that only Kotlin/
Native can see passes with no diff at all: an expect gaining a parameter, an actual narrowing
something, a declaration moving from commonMain into jvmMain and quietly disappearing from every
other target. platformHttpClient is an expect today and kdrant-migrate compiles for nine targets,
so the surface where this can happen is no longer hypothetical. STABILITY.md says the public API is
exactly what the committed *.api files track. For an iOS consumer that sentence is currently a promise
about a file that does not describe their artifact.
binary-compatibility-validator has klib validation for this, producing a .klib.api alongside the JVM
dump. It is a plugin option and a regenerated set of files rather than new machinery, which is the
argument for doing it now: the cost is one line and a apiDump while there are three multiplatform
modules, and it only grows.
Two things to settle while doing it. The klib dump is a merged, target-annotated file rather than one
per target, so a declaration present on some targets and not others is visible in the diff, which is
the case worth catching. And the dump has to be generated on a host that can build the Apple targets,
so the job that regenerates it is the macOS one, and CONTRIBUTING has to say so before someone commits
a dump with the Apple declarations missing.
Exit criterion: ./gradlew apiDump writes a .klib.api for every multiplatform module, apiCheck
fails on a change visible only from a native target, and CONTRIBUTING names the host the dump has to be
regenerated on.
Three modules are Kotlin Multiplatform now, and
apiChecktracks one.apifile per module: the JVMone. Everything the validator is relied on for is therefore a statement about a single target.
That is a smaller guarantee than it reads as. A change to a
commonMaindeclaration that only Kotlin/Native can see passes with no diff at all: an
expectgaining a parameter, anactualnarrowingsomething, a declaration moving from
commonMainintojvmMainand quietly disappearing from everyother target.
platformHttpClientis anexpecttoday andkdrant-migratecompiles for nine targets,so the surface where this can happen is no longer hypothetical. STABILITY.md says the public API is
exactly what the committed
*.apifiles track. For an iOS consumer that sentence is currently a promiseabout a file that does not describe their artifact.
binary-compatibility-validator has klib validation for this, producing a
.klib.apialongside the JVMdump. It is a plugin option and a regenerated set of files rather than new machinery, which is the
argument for doing it now: the cost is one line and a
apiDumpwhile there are three multiplatformmodules, and it only grows.
Two things to settle while doing it. The klib dump is a merged, target-annotated file rather than one
per target, so a declaration present on some targets and not others is visible in the diff, which is
the case worth catching. And the dump has to be generated on a host that can build the Apple targets,
so the job that regenerates it is the macOS one, and CONTRIBUTING has to say so before someone commits
a dump with the Apple declarations missing.
Exit criterion:
./gradlew apiDumpwrites a.klib.apifor every multiplatform module,apiCheckfails on a change visible only from a native target, and CONTRIBUTING names the host the dump has to be
regenerated on.