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

Code references

The docs rely on external references for versioning, which need to be updated accordingly:

• #npm-tag-reference: the npm tag corresponding to where the code is published.
• #host-reference: the URL corresponding to where the docs are deployed.
• #target-branch-reference: the git branch corresponding to where the code is worked on.

Legacy:

• #default-branch-switch includes all the above, but without being clear.

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.