Release phases

When there is a new major release for the products, the release process goes through 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.