...
If we are confident about the stability of the main branch then we can be flexible with our release schedule.
There are many details we could discuss further such as deprecation policy, feature toggles, improved regression testing, and burn-in procedure, but will focus on getting buy-in for the main point of this proposal first.
I will mention one interesting suggestion Gary made that we could treat our (currently internal) burn-in period as a beta release that is announced. We may then gain a better diversity of testing from the community, which is one benefit of the quarterly release candidates (that we don't particularly utilise currently).
Suggested Deprecation Policy
- Have an "Upcoming breaking changes" section in the changelog, which announces features that would have otherwise gone in a 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.
Discussion
Discussion points from last call and my responses from Discord, copied from #besu-release. Some questions outstanding...
...