Proposal: Quarterly releases from main by default - 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 / Proposal: Quarterly releases from main by default More actions Proposal: Quarterly releases from main by default Simon Dudley Owned by Simon Dudley Last updated: Aug 01, 2023 This is a refinement to the proposal: Avoid Cherry Picked Releases Goal: Make releasing as easy as possible Suggested Solution: Don't use RCs for Quarterly releases (by default) We sometimes already do this, for example with 23.7.0. We can still soak for a longer period of time than normal for riskier changes and we can advertise our soak to beta testers if we wish. We can still use a release branch if we feel the need, this proposal just suggests by default  we try to release from main. There is no need for this proposal to change the concept or versioning of quarterly releases and what they might signal (more significant changes). What needs to change? Some sort of notification about upcoming breaking changes, the obvious place being in the changelog/release notes ahead of the change landing. Suggested Deprecation Policy Have an "Upcoming breaking changes" section in the changelog, which announces features that are upcoming, e.g. a warning about big changes in the next quarterly release. Time it needs to be in changelog before releasing is at maintainers' discretion. Feature/branch/PR management of upcoming feature is at maintainers' discretion. Optionally add target release/date. , multiple selections available, Related content More info Collapse Proposal: Avoid Cherry Picked Releases Proposal: Avoid Cherry Picked Releases Besu More like this Future Release Dates Future Release Dates Besu More like this Release Rotations 2022 Release Rotations 2022 Besu More like this Release Process Improvement Release Process Improvement Besu More like this Off-cycle release process Off-cycle release process Besu More like this Proposal: Increasing 1.4 RC/Beta window Proposal: Increasing 1.4 RC/Beta window Besu More like this {"serverDuration": 12, "requestCorrelationId": "cc1acdee01204ee38d11a4ab63feb0f4"}