...
For example, Besu's policy would be:
- Besu has triannual to quarterly major releases. These are numbered YY.QM.0, such as 20.39.0.
- These releases undergo a two week beta and two week RC cycle,
- All supported public networks are synchronized and validated to stay in sync
- Besu has fortnightly patch releases. These are numbered YY.QM.PATCH, such as 20.39.1
- These releases come off of continuous integration releases
- A smaller number of select networks are re-synchronized, and previously nodes are upgraded and observed for 24 hours prior to release.
- Breaking changes are only introduced in quarterly changes
- These should have an entire quarter of notice, for example if notice of a breaking change is given in 20.12.4 then 20.25.0 should not implement the change but instead warn that 20.38.0 will implement the change
- These must be placed prominently at the top of the CHANGELOG for the quarterly release and each patch release for the notice period should reference it.
- If Besu exposes external libraries (such as JNI libraries for cryptography), those should continue to use SemVer.
- Internal versioning of build modules will use CalVer, providing a clear delineation as to what is an API and what isn't.
...