-
Notifications
You must be signed in to change notification settings - Fork 0
/
PatchReleaseChecklist.html
260 lines (217 loc) · 15.4 KB
/
PatchReleaseChecklist.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Patch Release Checklist</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=fa44fd50" />
<link rel="stylesheet" type="text/css" href="_static/bootstrap-sphinx.css?v=fadd4351" />
<link rel="stylesheet" type="text/css" href="_static/custom.css?v=77160d70" />
<script src="_static/documentation_options.js?v=a8da1a53"></script>
<script src="_static/doctools.js?v=9bcbadda"></script>
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Technical Steering Committee" href="TSC.html" />
<link rel="prev" title="Release Checklist" href="ReleaseChecklist.html" />
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-59110517-1', 'auto');
ga('send', 'pageview');
</script>
</head><body>
<div id="navbar" class="navbar navbar-default ">
<div class="container">
<div class="navbar-header">
<!-- .btn-navbar is used as the toggle for collapsed navbar content -->
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".nav-collapse">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="http://www.mantidproject.org">
</a>
<span class="navbar-text navbar-version pull-left"><b>main</b></span>
</div>
<div class="collapse navbar-collapse nav-collapse">
<ul class="nav navbar-nav">
<li class="divider-vertical"></li>
<li><a href="index.html">Home</a></li>
<li><a href="https://download.mantidproject.org">Download</a></li>
<li><a href="https://docs.mantidproject.org">User Documentation</a></li>
<li><a href="http://www.mantidproject.org/contact">Contact Us</a></li>
</ul>
<form class="navbar-form navbar-right" action="search.html" method="get">
<div class="form-group">
<input type="text" name="q" class="form-control" placeholder="Search" />
</div>
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
<p>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="nav-item nav-item-0"><a href="index.html">Documentation</a> »</li>
<li class="nav-item nav-item-this"><a href="">Patch Release Checklist</a></li>
</ul>
</div> </p>
</div>
<div class="container">
<div class="row">
<div class="body col-md-12 content" role="main">
<section id="patch-release-checklist">
<span id="patchreleasechecklist"></span><h1>Patch Release Checklist<a class="headerlink" href="#patch-release-checklist" title="Link to this heading">¶</a></h1>
<nav class="contents local" id="contents">
<ul class="simple">
<li><p><a class="reference internal" href="#request" id="id1">Request</a></p></li>
<li><p><a class="reference internal" href="#authorisation" id="id2">Authorisation</a></p></li>
<li><p><a class="reference internal" href="#development" id="id3">Development</a></p>
<ul>
<li><p><a class="reference internal" href="#release-notes" id="id4">Release Notes</a></p></li>
<li><p><a class="reference internal" href="#cherry-picking-code-review" id="id5">Cherry Picking & Code Review</a></p></li>
</ul>
</li>
<li><p><a class="reference internal" href="#nightly-builds" id="id6">Nightly Builds</a></p></li>
<li><p><a class="reference internal" href="#release-procedure" id="id7">Release Procedure</a></p></li>
</ul>
</nav>
<p>These are the steps involved in performing a Mantid patch release. To
perform a full release see <a class="reference internal" href="ReleaseChecklist.html#releasechecklist"><span class="std std-ref">Release Checklist</span></a>.</p>
<section id="request">
<h2><a class="toc-backref" href="#id1" role="doc-backlink">Request</a><a class="headerlink" href="#request" title="Link to this heading">¶</a></h2>
<ul class="simple">
<li><p>Anyone may request a patch release, but that request must be initially
approved by one of the local PMs.</p></li>
</ul>
</section>
<section id="authorisation">
<h2><a class="toc-backref" href="#id2" role="doc-backlink">Authorisation</a><a class="headerlink" href="#authorisation" title="Link to this heading">¶</a></h2>
<ul class="simple">
<li><p>The Technical Working Group must meet to authorise the patch release.</p></li>
<li><p>During the meeting other high value, low impact changes may be
considered for inclusion for the release. Any that are to be included
must be added to the patch release notes.</p></li>
<li><p>The Project Manager will create a new milestone in github, and all
tickets to be included must be moved to that milestone.</p></li>
<li><p>A developer will be nominated to be the main reviewer and compiler of
the patch.</p></li>
</ul>
</section>
<section id="development">
<h2><a class="toc-backref" href="#id3" role="doc-backlink">Development</a><a class="headerlink" href="#development" title="Link to this heading">¶</a></h2>
<p>The patch release will be prepared based off the tag used to mark
the last minor release. A branch called <code class="docutils literal notranslate"><span class="pre">release-next</span></code> will be created from this tag.
Normally, the <code class="docutils literal notranslate"><span class="pre">release-next</span></code> branch will already be pointing to the correct commit.
Verify that this is the case, and if not, update the branch so that it is.
Changes for the patch should be incorporated into the release branch by either of the following methods:</p>
<ul class="simple">
<li><p>If changes have already been merged into <code class="docutils literal notranslate"><span class="pre">main</span></code>, the commits should be cherry-picked into the release
branch (see <a class="reference internal" href="#cherry-picking"><span class="std std-ref">Cherry Picking</span></a>)</p></li>
<li><p>Any changes that have not yet been merged into <code class="docutils literal notranslate"><span class="pre">main</span></code> can be rebased so that the pull request targets
<code class="docutils literal notranslate"><span class="pre">release-next</span></code>. When they are merged, the changes will be automatically merged into <code class="docutils literal notranslate"><span class="pre">main</span></code>.</p></li>
</ul>
<p>Issues and pull requests should then have the <code class="docutils literal notranslate"><span class="pre">PatchCandidate</span></code> label applied to them.</p>
<section id="release-notes">
<h3><a class="toc-backref" href="#id4" role="doc-backlink">Release Notes</a><a class="headerlink" href="#release-notes" title="Link to this heading">¶</a></h3>
<p>The main reviewer should create a skeleton set of patch release notes on the release branch
using the <a class="reference external" href="https://www.github.com/mantidproject/mantid/blob/main/tools/release_generator/patch.py">python helper tool</a>.
For example:</p>
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>python<span class="w"> </span>release_generator/patch.py<span class="w"> </span>--release<span class="w"> </span><span class="m">6</span>.9.1<span class="w"> </span>-p<span class="w"> </span><span class="m">37033</span><span class="w"> </span><span class="m">37047</span><span class="w"> </span><span class="m">37014</span><span class="w"> </span><span class="m">37016</span><span class="w"> </span><span class="m">36935</span>
</pre></div>
</div>
<p>where the numbers after the <code class="docutils literal notranslate"><span class="pre">-p</span></code> argument are a list of existing pull requests to be included in the patch release.
Any future pull requests will need to be manually added to the release notes.
You will need to move the generated file to a <a class="reference external" href="https://github.com/mantidproject/mantid/tree/main/docs/source/release">new vX.Y.Z directory</a>
and add it to the <a class="reference external" href="https://github.com/mantidproject/mantid/blob/main/docs/source/release/index.rst">release notes index</a>.
Note that the <a class="reference external" href="https://github.com/mantidproject/mantid/blob/main/.github/workflows/automerge.yml">automerge</a> GitHub
action will probably fail with a conflict in the main index file. This will need to be resolved manually.</p>
</section>
<section id="cherry-picking-code-review">
<span id="cherry-picking"></span><h3><a class="toc-backref" href="#id5" role="doc-backlink">Cherry Picking & Code Review</a><a class="headerlink" href="#cherry-picking-code-review" title="Link to this heading">¶</a></h3>
<p>It is the job of the main reviewer of the release to review each
issue/pull request marked <code class="docutils literal notranslate"><span class="pre">PatchCandidate</span></code> and decide if the risks of
the changes are low enough to include in a release that will not
undergo full beta testing by scientists. New pull requests that target
<code class="docutils literal notranslate"><span class="pre">release-next</span></code> can simply be merged provided that they add the appropriate
release notes. Existing pull requests that have already been merged into <code class="docutils literal notranslate"><span class="pre">main</span></code>
should have their commits cherry-picked into the <code class="docutils literal notranslate"><span class="pre">release-next</span></code> branch,
either directly or via a new pull request branch. One advantage of creating
a new pull request branch is that you can ask the commit authors to verify
that all of the relevant commits have been added. For each of the <code class="docutils literal notranslate"><span class="pre">PatchCandidate</span></code>
pull requests that were not merged directly into <code class="docutils literal notranslate"><span class="pre">release-next</span></code>:</p>
<ul class="simple">
<li><p>find the list of commit <code class="docutils literal notranslate"><span class="pre">SHA1</span></code> values in that pull request</p></li>
<li><p>check if any of these commits has altered the release notes for the
next major release</p></li>
<li><p>if not then pass all commits in the order oldest->newest to
<code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">cherry-pick</span> <span class="pre">-x</span></code></p></li>
<li><p>if release notes were modified in a commit on their own then pass all
commits except this one in the order oldest->newest to
<code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">cherry-pick</span> <span class="pre">-x</span></code></p></li>
<li><p>if a commit has a mixture of code/release note changes then:</p>
<ul>
<li><p>pass the list of commits up to but not including this commit to
<code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">cherry-pick</span> <span class="pre">-x</span></code></p></li>
<li><p>now pass this single commit to <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">cherry-pick</span> <span class="pre">-x</span> <span class="pre">-n</span></code> and it
will not make a commit. Remove the major release note changes and
commit <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">add</span></code>/<code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">commit</span></code></p></li>
<li><p>if there are any remaining commits after this then pass them to
<code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">cherry-pick</span> <span class="pre">-x</span></code> as before.</p></li>
</ul>
</li>
<li><p>finally add a commit that updates the patch release notes with this
pull request link and summary description.</p></li>
</ul>
<p>Once cherry picked the milestone of the original pull request should be
updated to the patch milestone.</p>
</section>
</section>
<section id="nightly-builds">
<h2><a class="toc-backref" href="#id6" role="doc-backlink">Nightly Builds</a><a class="headerlink" href="#nightly-builds" title="Link to this heading">¶</a></h2>
<p>The <a class="reference external" href="https://builds.mantidproject.org/view/Nightly%20Pipelines/job/release-next_nightly_deployment">release-next nightly pipeline</a>
job checks for changes on the current release branch each night (00:00 GMT) and should
be monitored during the patch release period to check for any failures.</p>
</section>
<section id="release-procedure">
<h2><a class="toc-backref" href="#id7" role="doc-backlink">Release Procedure</a><a class="headerlink" href="#release-procedure" title="Link to this heading">¶</a></h2>
<p>Once all the changes have been merged into <code class="docutils literal notranslate"><span class="pre">release-next</span></code>, and the release notes
are complete, it is time to release the patch by performing the following tasks:</p>
<ul class="simple">
<li><p>Build the release candidates by following the instructions to <a class="reference internal" href="ReleaseChecklist.html#technical-release-manager-release-candidates"><span class="std std-ref">Create Final Release Candidates</span></a>.</p></li>
<li><p>After the release candidates have built successfully, ask the development team perform unscripted testing,
with a focus on the areas that were modified for the patch release.</p></li>
<li><p>When you are happy with the quality of the release candidates, follow all of the
<a class="reference internal" href="ReleaseChecklist.html#technical-release-manager-release-day"><span class="std std-ref">Release Day</span></a> instructions to publish the packages.</p></li>
<li><p>Once packages are published, the Project Manager must announce the patch release by following the
<a class="reference internal" href="ReleaseChecklist.html#release-manager-announcements"><span class="std std-ref">Release Day</span></a> instructions.</p></li>
</ul>
</section>
</section>
</div>
</div>
</div>
<footer class="footer">
<div class="container">
<ul class="nav navbar-nav" style=" float: right;">
<li>
<a href="ReleaseChecklist.html" title="Previous Chapter: Release Checklist"><span class="glyphicon glyphicon-chevron-left visible-sm"></span><span class="hidden-sm hidden-tablet">« Release Checklist</span>
</a>
</li>
<li>
<a href="TSC.html" title="Next Chapter: Technical Steering Committee"><span class="glyphicon glyphicon-chevron-right visible-sm"></span><span class="hidden-sm hidden-tablet">Technical Ste... »</span>
</a>
</li>
<li><a href="#">Back to top</a></li>
</ul>
<p>
</p>
</div>
</footer>
</body>
</html>