ABI validation too strict

[fire-light42]

It looks like the now merged ABI validation pull request complains when classes are made @Serializable, or when var is changed to val.

I do think we need it, but it triggers on almost any change, including changes which are fine. What are your opinions @Luna712

[Luna712]

Hmm. We could add an @PublicAPI annotation and set the ABI validation to only care about that? I am not really sure what the best way about it is...

[fire-light42]

What about a Gradle task which strips the ABI of any "safe" properties such as public final fun serialize?

[Luna712]

That would likely break configuration cache

[fire-light42]

I suppose contributors will need to run library:updateKotlinAbi and I can review the ABI changes manually.

[Luna712]

I feel like that would cause a lot of merge conflicts and also make the feature a little less useful

[Luna712]

@fire-light42 what if I make a workflow that we can use to update the ABI just like the /run-tests thing or manually triggered? I am not sure if it will work on forks but it might. Was just having a random thought to make it easier for contributors because them having to run it for simple things like extractor changes will be quite inconvenient I think...

[Luna712]

@fire-light42 also an issue where if the update is ran on a different JVM version the CI fails. CI runs with Java 17, I have Java 25 installed that I ran ./gradlew library:updateKotlinAbi on causing a mismatch and failure in CI by adding certain methods that newer java generates that older does not.

[fire-light42]

I think a manually triggered workflow would be the best solution, especially if the update is version dependent. 👍