at_client_sdk
at_client_sdk copied to clipboard
atsign-foundation
Public API verification
Is your feature request related to a problem? Please describe. at_client_mobile 3.2.0 had breaking changes that were published as a minor release.
Describe the solution you'd like A better way to ensure that breaking changes are caught and published appropriately (as a major version change).
Describe alternatives you've considered
- Build & implement a public API analyzer tool
- Use the spec/impl pattern more widely
- Write tests to ensure that the public api remains covered
Additional context no. 3 has the downside of adding an additional layer of maintenance to our code, every addition to the public api will have to be reflected in the tests. If something isn't added accordingly, then it is possible that we have future occurrences of the original problem.
@gkc I would like to pursue number 1. I think we could benefit from our own analyzer built with the intention of it being run in at_mono. The idea is that it analyzes our trunk against latest on pub.dev.
This grew into 8-13 SP, a number of my other cards will be moved to PR 44
@gkc is this something I should look at continuing work on? unit tests are another easy way for us to gain coverage of this, and unit tests are much easier to maintain. (unit tests also won't fail when they are intentionally updated for an intentional breaking change, but this will)