On 17 Sep 2020 the Hyperledger TSC voted to Allow projects to use CalVer or SemVerThis proposal would be for Besu to switch to CalVer for the next quarterly release. Besu has now switched to using CalVer for its 20.10.0 (f.k.a. 1.6.0) release. 

General background on Calendar Versioning (CalVer) - https://calver.org/

CalVer taxonomy: YY.M.patch

  • YY: Year (20, 21, 22, etc.)
  • M: Month (1, 2, 3, ..., 11, 12). 
  • Patch: Fortnightly releases, or whenever non-quarterly releases happen Ideally, no breaking changes, like our current policy is.
  • YY.M.patch: The year and month are from the current “quarterly” release. Not the current month. The YY.M value is set during the first release candidate. For example, if we release 20.10.0-RC1 in late October, and the proper release goes out in November, it will still be 20.10.0. Then, the patch value is the only one that will be incremented until the next quarterly release. For example, the next release will increment to 20.10.1, 20.10.2, 20.10.3, etc. even as patches are released in November, December and January 20201. 

The YY.M.0 release indicates a release that underwent harsher than normal QA processes and testing, and is also a release where users should be sure to check for breaking changes.

Breaking Changes Policy

  • No intentional backwards incompatible breaking changes should occur within a YY.M release cycle
    • Java Plugin APIs
    • CLI flags and configuration files
    • On-disk storage compatibility
  • Patches may introduce forwards compatible changes, such as (but not limited to) new features, new fork or chain support, and new JSON-RPC apis.
  • A notice for an intentional breaking change should be in the CHANGELOG.md file for at least a full quarterly release cycle. 
  • Examples of such changes:
    • Changing the required JDK.  (such as when we went form Java 8 to Java 11).
    • Removing storage formats, or required migrations.
    • Dropping obsolete CLI flags, such as the whitelist series flags (replaced by the allowlist series)
  • This breaking change policy will not prohibit rapid release of security related updates.
  • No labels