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

Code references

The docs rely on external references to be versioned correctly (references to values that need to be updated over time):

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

Legacy:

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

Releases

<aside> 🥷

Private

</aside>

Template: ‣