Hi everyone, We are kicking off our preparations for the next major version of Superset. Following our release process <https://github.com/apache/superset/issues/26015>, we are from this moment, gathering breaking change proposals <https://github.com/orgs/apache/projects/292>, 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 4.0 (check our release process <https://github.com/apache/superset/issues/26015> for more details): January 4th to January 10th > Committers and PMC members place proposed changes on the project kanban board > <https://github.com/orgs/apache/projects/292>, ready to be proposed for > consensus. Proposals will not be accepted after January 10th. If you miss the deadline, you’ll need to wait for the next breaking window. January 11th to January 14th > 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 > <mailto: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 15th to February 15th > 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 16th to March 15th The next phase is to generate a release with the breaking changes. At this point, we implement a series of practices to accelerate the release process: > We add messages to the #release-announcements > <https://apache-superset.slack.com/archives/CH307T4JG> and > #community-announcements > <https://apache-superset.slack.com/archives/C7G8CG0LR> 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 engage with the community through discussions (example > <https://github.com/apache/superset/discussions/24581>) for each release > candidate to ensure the release is as stable as possible. > To successfully validate the release, we follow Apache's voting process > <https://www.apache.org/foundation/voting.html>. The target date for releasing 4.0 is March 15th. Join the #release-announcements <https://apache-superset.slack.com/archives/CH307T4JG> channel for updates about the release. Best regards, Michael
