Track publicly exposed APIs for semantic versioning

[Happypig375]

No description provided.

[Happypig375]

@charlesroddie

[charlesroddie]

I'm not interested in looking at the changed code but maybe some answers to these questions would help?

• Is it just used in the releasing process and doesn't affect anyone who doesn't do releases?
• Are there are significant existing difficulties with knowing what major features are added in each release? Presumably the current approach involves scanning the completed PR history every few months or years. Does any reduction in this difficulty outweigh managing and maintaining the additional code and complexity in yml pipelines, than doing it the current way?

If all answers are yes then it's probably OK.

[Happypig375]

Is it just used in the releasing process and doesn't affect anyone who doesn't do releases?

There is a CI check that code files are properly formatted with no warnings in code. An untracked public API will now emit a warning but the fix is simple - just apply the code fix in the IDE (just a few clicks) and commit the result, or I do it myself. It doesn't block the build locally.

Are there are significant existing difficulties with knowing what major features are added in each release?

The Nightly workflow already invokes Release Drafter which updates the Draft Release every merge. It is unrelated to this PR - this PR tracks the API surface for following Semantic Versioning. Semantic Versioning mandates that breaking changes after version 1 update the major version number. I think it's about time we care about breaking changes because obviously this library is used in production now.

Presumably the current approach involves scanning the completed PR history every few months or years.

Release Drafter currently handles release notes, which is not the focus of this PR, this PR handles breaking change tracking in the public API surface.

Does any reduction in this difficulty outweigh managing and maintaining the additional code and complexity in yml pipelines, than doing it the current way?

The alternative is to silently accept breaking changes in the public API which is what we do now with a major version number 0, or manually check that the public API surface is unchanged which is unfathomable.

[charlesroddie]

Marking as approved on the basis that @Happypig375 is dealing with all of this!