This is not an official policy yet, but work-in-progress!

It will be published more loudly once the release engineering team has agreed on it and the details are polished.

Handling of branches

Branching for a new major release branch

We try to branch for a new major release branch about once a year. This is not a date controlled process, and requires some coordination. Before we get ready to branch, the driving release engineer will

• Push maintainers of stuff mentioned in doc/3RDPARTY and get feedback about missing or planned updates.
• Coordinate with the toolchain team to allow for a single gcc/binutils tree on the branch, by making sure only a single one of each is active and deleting the unused ones post-branch.
• Publicaly announce a tentative branch date, pointing at this policy, asking developers to not rush in anything last minute before the branch, and ask for allowance if they are unsure on some mostly-done change. See below for a strict post-branch backout rule in case any last minute changes cause issues.

When getting close to the announced branch date, a reminder will be sent out asking developers to exercise extra care with all further commits until the branch has happened.

Handling of new major release branches in the first few weeks

Since we only know how good a branch point was after the fact and when first test results for the new branch become available (which might be delayed by setup requiring a few days after the branch happened), the first few weeks of the new branch will be monitored more closely.

If the release engineering team decides some changes that went in later before the branch, the offending changes will be backed out on the branch.

General rules for pullups before the first release on a branch

• No feature additions (whatever small) will be pulled up
• No third-party updates will be pulled up
• Any pullups that cause new test failures or build breakage will be backed out immediately (and postponed after the first release). The release engineering team might make exceptions from this rule if the fix is clear and quick, in cooperation with the requesting developer.
• The first release should not be delayed longer than four months after the branch has been created. Any pending changes will go in for the first dot-one release two months later.

General rules for pullups for all release branches

• TBD - copy the existing policy over here
• The developers processing pullups are requested to immediately revert all pullup request that appear to not have been tested (or obviously are broken). The branch should be buildable and and tests in good shape always.

Timeline

The release engineering team will try to meet the following timeline

• One new major branch and release per year
• One point release for the newest stable branch every other month
• One point release for the old stable branch every quarter