1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
4 <meta http-equiv=
"content-type" content=
"text/html; charset=utf-8">
5 <title>Releasing Process
</title>
6 <link rel=
"stylesheet" type=
"text/css" href=
"mesa.css">
11 The Mesa
3D Graphics Library
14 <iframe src=
"contents.html"></iframe>
18 <h1>Releasing Process
</h1>
21 <li><a href=
"#overview">Overview
</a></li>
22 <li><a href=
"#schedule">Release schedule
</a></li>
23 <li><a href=
"#pickntest">Cherry-pick and test
</a></li>
24 <li><a href=
"#stagingbranch">Staging branch
</a></li>
25 <li><a href=
"#branch">Making a branchpoint
</a></li>
26 <li><a href=
"#release">Making a new release
</a></li>
27 <li><a href=
"#announce">Announce the release
</a></li>
28 <li><a href=
"#gitlab">Update Gitlab Issues
</a></li>
32 <h2 id=
"overview">Overview
</h2>
35 This document uses the convention X.Y.Z for the release number with X.Y being
36 the stable branch name.
40 Mesa provides feature and bugfix releases. Former use zero as patch version (Z),
41 while the latter have a non-zero one.
48 Mesa
10.1.0 -
10.1 branch, feature
49 Mesa
10.1.4 -
10.1 branch, bugfix
50 Mesa
12.0.0 -
12.0 branch, feature
51 Mesa
12.0.2 -
12.0 branch, bugfix
55 <h2 id=
"schedule">Release schedule
</h2>
58 Releases should happen on Wednesdays. Delays can occur although those
59 should be kept to a minimum.
63 See our
<a href=
"release-calendar.html" target=
"_parent">calendar
</a>
64 for information about how the release schedule is planned, and the
65 date and other details for individual releases.
68 <h2>Feature releases
</h2>
70 <li>Available approximately every three months.
</li>
71 <li>Initial timeplan available
2-
4 weeks before the planned branchpoint (rc1)
72 on the mesa-announce@ mailing list.
</li>
73 <li>Typically, the final release will happen after
4
74 candidates. Additional ones may be needed in order to resolve blocking
75 regressions, though.
</li>
78 <h2>Stable releases
</h2>
80 <li>Normally available once every two weeks.
</li>
81 <li>Only the latest branch has releases. See note below.
</li>
85 Note: There is one or two releases overlap when changing branches. For example:
89 The final release from the
12.0 series Mesa
12.0.5 will be out around the same
90 time (or shortly after)
13.0.1 is out.
94 This also involves that, as a final release may be delayed due to the
95 need of additional candidates to solve some blocking regression(s),
96 the release manager might have to update
97 the
<a href=
"release-calendar.html" target=
"_parent">calendar
</a> with
98 additional bug fix releases of the current stable branch.
102 <h2 id=
"pickntest">Cherry-picking and testing
</h2>
105 Commits nominated for the active branch are picked as based on the
106 <a href=
"submittingpatches.html#criteria" target=
"_parent">criteria
</a> as
107 described in the same section.
111 Nominations happen via special tags in the commit messages, and via gitlab
112 merge requests against the staging branches. There are special scripts used
117 The maintainer should watch or be in contact with the Intel CI team, as well
118 as watch the gitlab CI for regressions.
122 Cherry picking should be done with the '-x' switch (to automatically add
123 "cherry picked from ..." to the commit message):
127 git cherry-pick -x abcdef12345667890
131 Developers can request,
<em>as an exception
</em>, patches to be applied up-to
132 the last one hour before the actual release. This is made
<strong>only
</strong>
133 with explicit permission/request, and the patch
<strong>must
</strong> be very
134 well contained. Thus it cannot affect more than one driver/subsystem.
137 <p>Following developers have requested permanent exception
</p>
139 <li><em>Ilia Mirkin
</em></li>
140 <li><em>AMD team
</em></li>
143 <p>The gitlab CI must pass.
</p>
146 For Windows related changes, the main contact point is Brian
147 Paul. Jose Fonseca can also help as a fallback contact.
151 For Android related changes, the main contact is Tapani
152 P
älli. Mauro Rossi is collaborating with android-x86 and may
153 provide feedback about the build status in that project.
157 For MacOSX related changes, Jeremy Huddleston Sequoia is currently a
162 <strong>Note:
</strong> If a patch in the current queue needs any additional
163 fix(es), then they should be squashed together. The commit messages and the
164 "<code>cherry picked from
</code>"-tags must be preserved.
168 git show b10859ec41d09c57663a258f43fe57c12332698e
170 commit b10859ec41d09c57663a258f43fe57c12332698e
171 Author: Jonas Pfeil
<pfeiljonas@gmx.de
>
172 Date: Wed Mar
1 18:
11:
10 2017 +
0100
174 ralloc: Make sure ralloc() allocations match malloc()'s alignment.
176 The header of ralloc needs to be aligned, because the compiler assumes
179 (cherry picked from commit cd2b55e536dc806f9358f71db438dd9c246cdb14)
181 Squashed with commit:
183 ralloc: don't leave out the alignment factor
185 Experimentation shows that without alignment factor gcc and clang choose
188 (cherry picked from commit ff494fe999510ea40e3ed5827e7818550b6de126)
191 <h2>Regression/functionality testing
</h2>
194 <li><em>no regressions should be observed for Piglit/dEQP/CTS/Vulkan on Intel platforms
</em></li>
195 <li><em>no regressions should be observed for Piglit using the swrast, softpipe
196 and llvmpipe drivers
</em></li>
199 <h2 id=
"stagingbranch">Staging branch
</h2>
202 A live branch, which contains the currently merge/rejected patches is available
203 in the main repository under
<code>staging/X.Y
</code>. For example:
206 staging/
18.1 - WIP branch for the
18.1 series
207 staging/
18.2 - WIP branch for the
18.2 series
214 <li>People are encouraged to test the staging branch and report regressions.
</li>
215 <li>The branch history is not stable and it
<strong>will
</strong> be rebased,
</li>
219 <h2 id=
"branch">Making a branchpoint
</h2>
222 A branchpoint is made such that new development can continue in parallel to
223 stabilisation and bugfixing.
227 Note: Before doing a branch ensure that basic build and
<code>meson test
</code>
228 testing is done and there are little to-no issues. Ideally all of those should
233 Check if the version number is going to remain as, alternatively
234 <code> git mv docs/relnotes/{current,new}.html
</code> as appropriate.
238 To setup the branchpoint:
241 git checkout master # make sure we're in master first
242 git tag -s X.Y-branchpoint -m
"Mesa X.Y branchpoint"
245 $EDITOR VERSION # bump the version number
247 truncate docs/relnotes/new_features.txt
249 git push origin X.Y-branchpoint X.Y
254 <a href=
"https://gitlab.freedesktop.org/mesa/mesa/-/milestones" target=
"_parent">gitlab
</a> and add the new Mesa version X.Y.
258 Check that there are no distribution breaking changes and revert them if needed.
259 For example: files being overwritten on install, etc. Happens extremely rarely -
260 we had only one case so far (see commit
2ced8eb136528914e1bf4e000dea06a9d53c7e04).
263 <h2 id=
"release">Making a new release
</h2>
266 These are the instructions for making a new Mesa release.
269 <h3>Get latest source files
</h3>
272 Ensure the latest code is available - both in your local master and the
276 <h3 id=
"basictesting">Perform basic testing
</h3>
279 Most of the testing should already be done during the
280 <a href=
"#pickntest">cherry-pick
</a>
281 So we do a quick 'touch test'
286 <li>scons (from release tarball)
</li>
287 <li>the produced binaries work
</li>
291 Here is one solution:
295 __glxgears_cmd='glxgears
2>&1 | grep -v
"configuration file"'
296 __es2info_cmd='es2_info
2>&1 | egrep
"GL_VERSION|GL_RENDERER|.*dri\.so"'
297 __es2gears_cmd='es2gears_x11
2>&1 | grep -v
"configuration file"'
298 test
"x$LD_LIBRARY_PATH" != 'x'
&& __old_ld=
"$LD_LIBRARY_PATH"
299 export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/:
"${__old_ld}"
300 export LIBGL_DRIVERS_PATH=`pwd`/test/usr/local/lib/dri/
301 export LIBGL_DEBUG=verbose
306 export LIBGL_ALWAYS_SOFTWARE=true
311 export LIBGL_ALWAYS_SOFTWARE=true
312 export GALLIUM_DRIVER=softpipe
318 unset LD_LIBRARY_PATH
319 test
"x$__old_ld" != 'x'
&& export
LD_LIBRARY_PATH=
"$__old_ld" && unset __old_ld
320 unset LIBGL_DRIVERS_PATH
322 unset LIBGL_ALWAYS_SOFTWARE
324 export VK_ICD_FILENAMES=`pwd`/test/usr/local/share/vulkan/icd.d/intel_icd.x86_64.json
325 steam steam://rungameid/
570 -vconsole -vulkan
326 unset VK_ICD_FILENAMES
329 <h3>Create release notes for the new release
</h3>
332 The release notes are completely generated by the
333 <code>bin/gen_release_notes.py
</code> script. Simply run this script before
334 bumping the version, and commit the results.
336 The only thing left to do is add the sha256 sums.
340 Increment the version contained in the file VERSION at Mesa's top-level, then
345 Commit these changes and push the branch.
353 <h3>Use the release.sh script from xorg
<a href=
"https://cgit.freedesktop.org/xorg/util/modular/">util-modular
</a></h3>
356 Start the release process.
360 ../relative/path/to/release.sh . # append --dist if you've already done distcheck above
364 Pay close attention to the prompts as you might be required to enter your GPG
365 and SSH passphrase(s) to sign and upload the files, respectively.
368 <h3>Add the sha256sums to the release notes
</h3>
371 Edit docs/relnotes/X.Y.Z.html to add the sha256sum as available in the mesa-X.Y.Z.announce template. Commit this change.
374 <h3>Back on mesa master, add the new release notes into the tree
</h3>
377 Something like the following steps will do the trick:
381 git cherry-pick -x X.Y~
1
382 git cherry-pick -x X.Y
385 <p>Then run the
<pre>./bin/post_version.py X.Y.Z
</pre>, where X.Y.Z is the
386 version you just made. This will updated docs/relnotes.html,
387 docs/index.html, and docs/release-calendar.html. It will then generate
388 a git commit automatically. Check that everything looks correct and push:
392 git push origin master X.Y
396 <h2 id=
"announce">Announce the release
</h2>
399 Use the generated template during the releasing process.
403 Again, pay attention to add a note to warn about a final release in a
404 series, if that is the case.
408 <h2 id=
"gitlab">Update gitlab issues
</h2>
411 Parse through the bug reports as listed in the docs/relnotes/X.Y.Z.html
412 document. If there's outstanding action, close the bug referencing the commit
413 ID which addresses the bug and mention the Mesa version that has the fix.
417 Note: the above is not applicable to all the reports, so use common sense.