Description

I am quite new to python-semantic-release and started looking into it after watching Stephan Bönnemann's talk that you recommend in the readme. That kind of convinced me that my old versioning system (x.y, where x is based on a human specified tag like v1, y is number of commits since tag) isn't so great after all. One point that quite convinced me in Stephan's talk is the idea to detect unmarked breaking changes by running the previous version's test suite on a new version. If the new version fails the old version's tests, it's probably a breaking change.

Use cases

This is useful in two different scenarios:

1. A team member implemented a breaking change but didn't notice, because it's rather subtle
2. A team member implemented a breaking change but forgot to mention that point in the commit message
   In both cases, the automatically computed version increment would (incorrectly) be on the minor (feature) version rather than on the major (breaking) version. In these two cases, it would be useful to see an error message rather than having the new version be blindly created.

Possible implementation

I would imagine an option that allows users to enable this feature. Then after incrementing the version, but before (i) committing it to source control, we build the package and run a user defined test command on that package (or restrict that for the beginning by running a tox "environment").

I would be willing to put some time into writing this, if there is enough interest in having a feature like this.