Consider moving BCV to Kotlin repo

[qwwdfsad]

Currently, BCV is in a tough spot w.r.t the rest of the Kotlin tooling:

• It is tightly bound to the underlying Kotlin version (esp. with klib validation), though it has a completely different versioning. And it's unlikely to ever be properly forward-compatible
• Consequently, it means that we either have to make a release after each Koltin major release or use some non-trivial runtime dependency substitution to workaround the issue
• The Gradle DSL evolves independently from the rest of the KGP, meaning that API divergence is likely to be present -- some Kotlin tools support annotation-based exclusions, some annotation-based inclusions, some have different APIs, some have different Gradle compatibility policies etc.
  • We also need some expertise in modern Gradle to properly maintain all that
• This is de facto a standard Kotlin tool -- it leverages implementation knowledge, depends on the compiler internals and shapes/is shaped by our spec, and presumably should be used by most of the libraries in the wild. It's a bit awkward that some tools are available out of the box (i.e. testing, power asserts, JaCoCo coverage from Gradle) while BCV is an external dependency with awkward versioning and compatibility

It would be nice to make it part of the Kotlin offering by default, e.g. so users can write something like:

kotlin {
    ...
}

// Maybe in kotlin block. Mayble applied but disabled by default, maybe applicable via shorthand syntax like kotlin("api-validation")
abiValidation { 
    // Configure
}

[LouisCAD]

Point brought by @martinbonnin: Can we really say BCV is a validator, considering that it is only validating that nothing changes, and will happily fail when you add something that isn't even breaking binary compatibility?

Maybe binary compatibility tracker or something alike would be better?

Or maybe add a mode/task that can dump the API in a non-overwriting way, and would fail only if existing parts of the API are broken (requiring to accept or undo those breakages with an overwriting dump).

[JakeWharton]

That behavior is tracked by #187 and #140, and not really related to moving to the Kotlin repo.

[LouisCAD]

Sure, I was bringing it because I think such a change (moving it into the Kotlin repo) might also be an opportunity for a more correct name. Thanks for linking the issues!