Document versioning schema of JUnit 5 release numbers (Semver?)

[JLLeitschuh]

Question

Will this project's release numbers conform to Semver?

Inevitably in every project mistakes are made and the team realizes that API's that made sense once no longer do. Semver defines a versioning schema.

Many projects say that they conform to Semver but they ignore the 8th point:

8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.
- Semver Section 8

Many projects are afraid to bump the major version unless there is some major feature addition or wild rewrite of the API.
One exception to this is Google Guava's releases.
They will perform many major version releases in a year because they break API's. That team isn't afraid of the major version number.

That being said, they have a prominent warning in their README about their versioning.

The @API annotations are great; guava has something similar with their @Beta annotation.

Implications

If JUnit 5 decides to follow Semver and makes a release that has a breaking API change, it would be JUnit 6!

Deliverables

• Document detailing the release number versioning decisions of the JUnit Team

[marcphilipp]

Related: apiguardian-team/apiguardian#9

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. Thank you for your contribution.

[stale]

This issue has been automatically closed due to inactivity. If you have a good use case for this feature, please feel free to reopen the issue.