Suggest the next version number automatically

[keith-hall]

Hi,

Thanks for this great tool! One thing I would find very useful would be a way to get cargo-public-api to look at all changes on the current branch since the latest git tag, and based on what those are, suggest what version number the next release should have. (i.e. Increment the latest git tag's minor version by one if no breaking changes were made since the tag, increment the major version if there are breaking changes in the public api etc.)

Motivation: each release would be semver compliant without the user publishing the release needing to think about it too much. If everyone would use this feature when publishing crates, there would theoretically be no semver-incompliant releases... ;)

[Enselic]

Hi and thank you for this feature request :D

I understand how you think, but I am a bit afraid this would result in too frequent instances of bad advice, especially with regards to changed items. Changing return type from ActualStruct to Self is not necessarily a breaking change, for example. And maybe the tool detects removal of API, but that API is in practice is not used. Then the tool would erroneously propose a major bump. In short, I personally would not trust the advice of such a feature, I would need to make a judgement call on a case-by-case basis based on public API diff output.

But maybe the false positives are infrequent enough to make this worthwhile?

I guess we could experiment with adding an opt-in flag called something like --propose-semver-bump. If we do, I have some wishes for properties of such an implementation:

• The code should be isolated in its own module as much as possible, to not make the rest of the code base harder to maintain
• There needs to be a good set of automated tests in place, to not make the rest of the code base and feature set harder to maintain and develop
• As mentioned, I would like this to be opt-in rather than outputted by default.

Sorry for some negativity, but I figured it is best to set my personal expectations for this early on. As usual, I am very open to be convinced I am wrong.

[keith-hall]

Thanks for your frank response, considering my FR, and clearly setting your expectations - you certainly make some good points, and at the end of the day it's your project to maintain/develop :)

And maybe the tool detects removal of API, but that API is in practice is not used. Then the tool would erroneously propose a major bump.

Arguably, the correct thing to do is follow semver closely - in my opinion (I'm also happy to be proven wrong) there is no way to know for sure that an API is not used in practice - it could be used in a private git repo, or in someone's WIP personal project which hasn't been shared publicly (yet) etc. I personally think erring on the side of caution with major version bumps is the correct thing to do - it may be super easy for a consumer project to upgrade, the main point is never to have a potentially breaking change in a minor version bump. :) But yes, it's likely very subjective, so I am happy that we can have this interesting discussion :)

[joshka]

This can be done using https://github.com/obi1kenobi/cargo-semver-checks