Release Philosophy - Besu - LF Decentralized Trust Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window) PreferencesOnly necessaryAccept all LF Decentralized Trust LF Decentralized Trust Spaces Apps Templates Create Besu All content Shortcuts Meetings Meetings  This trigger is hidden How-to articles How-to articles  This trigger is hidden Content Results will update as you type. Code of Conduct Contributing Developing and Conventions Besu CLI Style Guide Coding Conventions Changelog Testing Debugging Besu in IntelliJ Releasing Release Rotations 2024 Using CalVer for Besu Releases How to do a Besu Release Off-cycle release process Release Process Obsolete Proposals and Policies Bi-Weekly & Quarterly Release Process Process change proposal: burn-in Proposal for Off-Cycle, Delayed, and Scuttled Releases Proposal: Avoid Cherry Picked Releases Proposal: Create a Release Candidate for every release Proposal: Increasing 1.4 RC/Beta window Proposal: Quarterly releases from main by default Release Philosophy Archive Bug Triage Process Policies Plugin Services Tools we use Advanced Repositories and other projects Archive (Dev) Changelog Improvement Proposal Logging Building from source Documentation Community Governance Programs & Grants Meetings Design Documents Security Audits Start Here Performance & Stability How-to articles Incident Reports Besu Roadmap & Planning How to Contribute You‘re viewing this with anonymous access, so some content might be blocked. Close Besu / Release Philosophy More actions Release Philosophy Sally MacFarlane Owned by Sally MacFarlane Last updated: Aug 26, 2021 The general philosophy behind Besu release numbering is as follows. We bump the milestone when a release is big enough (such as full Mainnet compliance). We do a quarterly release where we upgrade all dependencies with a RC release. Feature development is done on the main branch in GitHub. Significant features should include a feature flag so that the feature can be disabled by default. We don’t do feature branches. We do patch releases on a fortnightly cadence to allow access to bug fixes without delay. As for numbering itself, the following approach is used: "Major Version" means a version of the Software identified by a change in the digit to the left of the left-most decimal point (X.x.x). "Minor Version" means a version of the Software identified by a change in the middle number in between the two decimal points (x.X.x). "Maintenance Version" means a version of the Software identified by a change in the digit to the right of the rightmost decimal point (x.x.X). We are not using semantic versioning.  , multiple selections available, Related content More info Collapse Release Process Release Process Besu More like this Release Process Improvement Release Process Improvement Besu More like this Release Remediation Release Remediation Besu More like this Documentation release process Documentation release process Besu More like this Release Rotations 2023 Release Rotations 2023 Besu More like this Release Rotations 2021 Release Rotations 2021 Besu More like this {"serverDuration": 12, "requestCorrelationId": "70e5d18f9d44487da6ed636981c1bdda"}