Our release policy can be found in the documentation. In the guide, we focus on how releases are done.

Major versions

There are two slots in the year where we can release breaking changes:

The teams are responsible for choosing the actual week/date for their major version release, meaning they are expected to self-organize together with the EM and PM of those product lines.

The benefit of this approach is that the time to ship a version compatible with the latest version of a product line that is a direct dependency of another is shortened by half the time. In addition, it makes it easier for marketing and DevEx to prepare for the major releases upfront.

Release process

React - Major version release process

Frequency

Once a week.

WIP: ‣

Versioning

As much as possible, we aim to keep all the packages under a single version, especially for majors**.** This is important to minimize the complexity of figuring out which package is not compatible with another one. Instead, developers can upgrade everything to the same version, and it "just" works. It avoids them having to check and resolve the peer dependency constraints.

Tentative roadmap for up to 2026: ‣.

Pre-GA vs. GA (General Availability)

When working on new features, anytime we have doubts about one or multiple of those: