Our release policy can be found in the documentation. In the guide, we focus on how releases are done.
We have two time 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.
Once a week.
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.
There is a round-robin mechanism put in place. Each week, the next person in the team is supposed to take care of the release. This round-robin mechanism is designed to have each member own the end-to-end delivery of value to the users.
Once it's your turn, your role is to do the release and let know the next person the following week that it's its turn.