Hi everyone, We are kicking off our preparations for the next major version of Superset. Following our release process <https://github.com/apache/superset/wiki/Release-Process>, we are from this moment, gathering breaking change proposals, from committers and PMCs, to be submitted for lazy consensus. If you’re not a committer or PMC and wish to propose a breaking change, reach out to us on Slack. Keep in mind that proposals should be submitted only if authors have the intention to work on them during the breaking window.
Here’s the planned timeline for 5.0 (check our release process <https://github.com/apache/superset/wiki/Release-Process> for more details): *December 9th to December 16th* Committers and PMC members place proposed changes on the project kanban board <https://github.com/orgs/apache/projects/345>, ready to be proposed for consensus. Proposals will not be accepted after December 16th. If you miss the deadline, you’ll need to wait for the next breaking window. *December 17th to December 19th* An email with a batch of these proposed changes (numbered for convenience of reference) is sent for lazy consensus to the dev@superset.apache.org (dev@) list. The dev@ list has three days to object to any of these proposed changes individually (i.e., the batch, or “wave” of them is not completely struck down). After three days pass, if there is no objection, the changes are moved into a “consensus reached” state. *January 2nd to January 31st* We formally declare the opening of a breaking window by sending an email to the dev@ list for lazy consensus with the start and end dates of the window. Contributors track the state of approved breaking changes on the board until merged. The pull requests that materialize the breaking changes must have an atomic nature, in the sense that once merged we don't end up in an intermediate state if the window closes. Any items on the board that have not been proposed for consensus, or completed during the breaking change window, will be punted to the next major release. When we reach the end of the breaking window, we send another email to the dev@ list confirming that no more breaking changes are allowed. *February 3rd* We'll cut 5.0.0 RC1 and start testing the release. At this point, we implement a series of practices to accelerate the release process: We add messages to the #release-announcements and #community-announcements Slack channels stating that we're in a stabilization phase and asking for help from the community to keep the focus on fixes and testing. During our daily PR review meeting, we mark feature or refactor-related PRs with the review-after-release label to preserve the focus on the release. This will not restrict people from reviewing and merging a PR but just indicate that the community cannot prioritize the review. We'll create a GitHub project for each RC (example <https://github.com/orgs/apache/projects/437>) where the community can give feedback about the release. To successfully validate the release, we follow Apache's voting process. Join the #release-announcements channel for updates about the release. Best regards, Michael
