After feature freeze, pull requests for the release should be based on the delivery branch, limited to fixes, and labelled with priority:high or priority:critical if appropriate.
This page clarifies how that works in practice.
The release team handles all merging to delivery. The release team does not control what gets merged. All pull requests for delivery that pass review will be merged for the next release candidate if there is one.
- When opening a pull request against delivery (or rebasing an existing one), please be explicit about the reason for targeting delivery. That might just be a link to an issue if there is one.
- Checking suitability of a PR for delivery should be part of reviewing for everyone, and a reason for requesting changes or vetoing if really necessary.
- Anyone may label an issue or PR with high/critical priority, but the author is often the best person to make that call.
priority:high
means you think the PR is important and should, if at all possible, be included in the release.priority:critical
means you think the PR is critical, and must be included in the release.
- There will usually be a minimum of 3 release candidates for each release. A decision on further release candidates is usually based on the existence of high/critical priority issues or PR.
- Each release candidate adds about a week to the release timetable. We can sometimes shorten this where changes are limited in scope. Nothing is merged between last release candidate and vote (they are built from the same commit).
- If you open or retarget a PR against delivery after the last scheduled release candidate and label it with
priority:high
orpriority:critical
, you are saying that you believe the release needs to be delayed to get it in; if unlabelled, that it's OK if it doesn't make it in (and it probably won't).