Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider doing automated API surface area comparisons #2661

Open
baronfel opened this issue Sep 30, 2019 · 6 comments

Comments

@baronfel
Copy link

commented Sep 30, 2019

The issue

To prevent unintended API surface area drift, it might be useful to have a diff report as part of CI.

It should be possible to use a dotnet tool like synver to do the comparison. The tool also allows for suggesting version bumps based on the surface area difference, if that's desired.

If nothing else it could be a sanity check that major-api changes aren't being introduced accidentally, or could go so far as to automate version numbering for packages based off of its suggestions. All up to how you'd like to see it done.

@roji

This comment has been minimized.

Copy link
Member

commented Sep 30, 2019

This definitely seems like a valuable part of a CI pipeline.

It's worth mentioning that the breakage in 4.1.0 was due to some special circumstances - we were developing for 5.0 and knowingly introducing breaking changes - and only later at some point decided to turn it into a minor release (and didn't do a good job reverting stuff). That isn't too say we shouldn't have automated tooling, just that in Npgsql history we've generally been pretty ok even without one.

I definitely don't see us deciding on versions based on code changes - rather the opposite... :) Not sure who'd want to go so far as to manage version numbering automatically like that...!

@roji roji added this to the Backlog milestone Sep 30, 2019
@roji

This comment has been minimized.

Copy link
Member

commented Sep 30, 2019

Oh, I realize I may have misunderstood, and that the automatic version numbering is more of a way to assert that no breaking changes have been introduced etc. If so forget I said anything.

@baronfel

This comment has been minimized.

Copy link
Author

commented Sep 30, 2019

Yep, that's all I meant. You can do something like 'assert that the expected output of asking for a version bump is ', and if it ever fails that invariant that'd be a failing test. Then it becomes a planned change or commit or something to update that test baseline, for example.

@baronfel

This comment has been minimized.

Copy link
Author

commented Sep 30, 2019

There are also other tools in this space, I just like synver :)

@roji

This comment has been minimized.

Copy link
Member

commented Sep 30, 2019

Right, thanks for clarifying :) Then there's a baseline file where we put validated changes that wouldn't trip the build?

@baronfel

This comment has been minimized.

Copy link
Author

commented Sep 30, 2019

Not native to that tool, you'd have to do something like that manually on top of the tool output as far as I'm aware.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.