You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This plugin generates a file with all the public methods, and every time you either increase or decrease the public API, this file is gonna be changed and you could see the changes during the PR review, if it was an intentional change, all good, if it's by mistake, then you'd know before shipping the change, it's a preventive approach rather than reactive.
Example of the generated file. Example of the setup. Example generating the file.
When you run eg ./gradlew check but don't do ./gradlew apiDump before, the build is gonna fail if you increased/decreased the public API not intentionally.
Something to consider is also using the explicitApi Kotlin mode.
This will force you to set all the visibility modifiers in methods, properties, classes, etc, it could be a bit of boilerplate (eg setting all the classes to public - it is public by default already), but it is more explicit and is better for identifying breaking changes proactively.
The text was updated successfully, but these errors were encountered:
As an SDK, we should avoid breaking changes, whenever possible obviously.
Sometimes we'd do them, but then we'd need to increase a minor or major version if following semver.
The goal of this issue is to keep track of the Public API.
To do that, we could use the binary-compatibility-validator plugin.
This plugin generates a file with all the public methods, and every time you either increase or decrease the public API, this file is gonna be changed and you could see the changes during the PR review, if it was an intentional change, all good, if it's by mistake, then you'd know before shipping the change, it's a preventive approach rather than reactive.
Example of the generated file.
Example of the setup.
Example generating the file.
When you run eg
./gradlew check
but don't do./gradlew apiDump
before, the build is gonna fail if you increased/decreased the public API not intentionally.Something to consider is also using the explicitApi Kotlin mode.
This will force you to set all the visibility modifiers in methods, properties, classes, etc, it could be a bit of boilerplate (eg setting all the classes to
public
- it is public by default already), but it is more explicit and is better for identifying breaking changes proactively.The text was updated successfully, but these errors were encountered: