I'm working on libraries published as nuget packages and I would like the version of those packages to update automatically based on the changes I make.
In other words, I would like something that automatically adjusts the major, minor, and patch numbers based on the changes of the API surface of the library.
This should be possible if we define the "public API" mentioned in the SemVer specs as the actual public API surface from the assembly (public classes, interfaces, structs, enums, delegates, protected methods, etc.).
Let's say the current version of a LibraryA is
- If I change the signature of a public method, the version should become
- If I add a new public class, the version should become
- If I change the implementation of a private class, the version should become
Following amon's comment, I understand that behavioral changes can break compatibility. It is also unlikely that a tool could understand changes in behavior by comparing two assemblies.
I'm not looking for a perfect versioning solution. I think the API surface is a good start for an automated versioning system, especially considering that I have automated tests that validate behaviors.
- If it can be computed automatically, why should a human do it and potentially make mistakes?
- In an open-source collaboration context, having a tool tell you the level of change a pull request brings can help organize contributions. e.g. Contributions that bring breaking changes can be combined overtime to produce 1 major release each year.
Using an existing tool would be ideal, but I haven't found one that checks API surface yet.
If you know of a tool that does this, please let me know!
I know there are tools like GitVersion that compute a version number based on some metadata, but that metadata usually needs human input (like git tags, commit message, etc.), which is what I want to avoid.
Any other advice on how this could be custom-implemented is also welcome.