Release phases

When there is a new major release for the products, the release process goes into multiple phases:

• “pre-release”: prepare the release
• “alpha”: heavy breaking changes phase
• “beta”: all the breaking changes planned are done, focusing on finishing the work, unplanned BCs can still happen if required.
• “release candidate”: the work is done, try to increase the % adoption of the version.
• “stable”: general availability.
• “post-release”: clean-up after the release

Specificity for some projects

Core - Major version release process

MUI X - Major version release process

Pre-release

The stable version always uses master. The work toward the next major always happens on the next branch. We set the default branch on the active work, we very rarely have two active branches worked.

1. Rename the master branch to next.
2. Create a new branch master from the current next branch commit.
3. Update the scripts that run the CI to use the new branch correctly:
   1. Set next the default branch for Prettier https://github.com/mui/mui-x/pull/6097/files.
   2. Set next for the dependencies deduplication https://github.com/mui/material-ui/pull/41657.
   3. ? Add more if you find stuff
4. Create a migration guide docs page for the next major. For example:
   • https://github.com/mui/mui-x/pull/6235
   • https://github.com/mui/material-ui/pull/41561

From this point on, until the first alpha release and beyond, these activities should happen:

1. When introducing a breaking change:
   1. Add the breaking change GitHub label on the PRs and issues.
   2. Update the migration guide with a new entry.
   3. Update the PR description with clear migration instructions.