You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Markdown] Contributing: Add section about release branch PRs
In an effort to centralize the release branch PR form and release
process info in general, dedicate a section to this for repositories and
forum announcements to refer to instead of each publishing their own
copies.
Copy file name to clipboardExpand all lines: contributing/_contributing-code.md
+30
Original file line number
Diff line number
Diff line change
@@ -111,6 +111,36 @@ For C or C++ source or header files, the code header should look this:
111
111
112
112
The divider lines should be exactly 80 characters wide to aid in adherence to the code style guidelines. The bottom section contains an optional description intended for generated documentation (these lines begin with `///` rather than `//`). If there is no description, this area can be skipped.
113
113
114
+
### Release Branch Pull Requests
115
+
116
+
A pull request targeting a release branch (`release/x.y`) cannot be merged
117
+
without an approval by a corresponding branch manager.
118
+
In order for a change to be considered for inclusion in a release branch, the
119
+
pull request must have:
120
+
121
+
* A title that starts with a `[x.y]` tag matching the release version of the
122
+
target branch
123
+
124
+
* The following form filled out in its description:
125
+
126
+
```
127
+
- **Explanation**: A description of the changes. This can be brief, but it
128
+
should be clear.
129
+
- **Scope**: An assessment of the impact and importance of the changes. For
130
+
example, can the changes break existing code?
131
+
- **Issues**: References to issues the changes resolve, if any.
132
+
- **Original PRs**: Links to mainline branch pull requests in which the
133
+
changes originated.
134
+
- **Risk**: The (specific) risk to the release for taking the changes.
135
+
- **Testing**: The specific testing that has been done or needs to be done to
136
+
further validate any impact of the changes.
137
+
- **Reviewers**: The code owners that approved the original changes in the
138
+
mainline branch pull requests. If an original change has not been approved
139
+
by a respective code owner, provide a reason. Technical review can be
140
+
delegated by a code owner or otherwise requested as deemed appropriate or
141
+
useful.
142
+
```
143
+
114
144
### Code Review
115
145
116
146
The Swift project relies heavily on code review to improve software quality:
0 commit comments