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>
22 <li><a href=
"#schedule">Release schedule
</a>
23 <li><a href=
"#pickntest">Cherry-pick and test
</a>
24 <li><a href=
"#stagingbranch">Staging branch
</a>
25 <li><a href=
"#branch">Making a branchpoint
</a>
26 <li><a href=
"#prerelease">Pre-release announcement
</a>
27 <li><a href=
"#release">Making a new release
</a>
28 <li><a href=
"#announce">Announce the release
</a>
29 <li><a href=
"#gitlab">Update Gitlab Issues
</a>
33 <h2 id=
"overview">Overview
</h2>
36 This document uses the convention X.Y.Z for the release number with X.Y being
37 the stable branch name.
41 Mesa provides feature and bugfix releases. Former use zero as patch version (Z),
42 while the latter have a non-zero one.
49 Mesa
10.1.0 -
10.1 branch, feature
50 Mesa
10.1.4 -
10.1 branch, bugfix
51 Mesa
12.0.0 -
12.0 branch, feature
52 Mesa
12.0.2 -
12.0 branch, bugfix
56 <h2 id=
"schedule">Release schedule
</h2>
59 Releases should happen on Wednesdays. Delays can occur although those
60 should be kept to a minimum.
64 See our
<a href=
"release-calendar.html" target=
"_parent">calendar
</a>
65 for information about how the release schedule is planned, and the
66 date and other details for individual releases.
69 <h2>Feature releases
</h2>
71 <li>Available approximately every three months.
72 <li>Initial timeplan available
2-
4 weeks before the planned branchpoint (rc1)
73 on the mesa-announce@ mailing list.
74 <li>Typically, the final release will happen after
4
75 candidates. Additional ones may be needed in order to resolve blocking
77 <li>A
<a href=
"#prerelease">pre-release
</a> announcement should be available
78 approximately
24 hours before the final (non-rc) release.
81 <h2>Stable releases
</h2>
83 <li>Normally available once every two weeks.
84 <li>Only the latest branch has releases. See note below.
85 <li>A
<a href=
"#prerelease">pre-release
</a> announcement should be available
86 approximately
48 hours before the actual release.
90 Note: There is one or two releases overlap when changing branches. For example:
94 The final release from the
12.0 series Mesa
12.0.5 will be out around the same
95 time (or shortly after)
13.0.1 is out.
99 This also involves that, as a final release may be delayed due to the
100 need of additional candidates to solve some blocking regression(s),
101 the release manager might have to update
102 the
<a href=
"release-calendar.html" target=
"_parent">calendar
</a> with
103 additional bug fix releases of the current stable branch.
107 <h2 id=
"pickntest">Cherry-picking and testing
</h2>
110 Commits nominated for the active branch are picked as based on the
111 <a href=
"submittingpatches.html#criteria" target=
"_parent">criteria
</a> as
112 described in the same section.
116 Nomination happens in the mesa-stable@ mailing list. However,
117 maintainer is responsible of checking for forgotten candidates in the
118 master branch. This is achieved by a combination of ad-hoc scripts and
119 a casual search for terms such as regression, fix, broken and similar.
123 Maintainer is also responsible for testing in various possible permutations of
124 the meson and scons build.
127 <h2>Cherry-picking and build/check testing
</h2>
129 <p>Done continuously up-to the
<a href=
"#prerelease">pre-release
</a> announcement.
</p>
132 Developers can request,
<em>as an exception
</em>, patches to be applied up-to
133 the last one hour before the actual release. This is made
<strong>only
</strong>
134 with explicit permission/request, and the patch
<strong>must
</strong> be very
135 well contained. Thus it cannot affect more than one driver/subsystem.
138 <p>Following developers have requested permanent exception
</p>
140 <li><em>Ilia Mirkin
</em>
141 <li><em>AMD team
</em>
144 <p>The following must pass:
</p>
146 <li>meson test, scons and scons check
147 <li>Testing with different version of system components - LLVM and others is also
148 performed where possible.
149 <li>As a general rule, testing with various combinations of configure
150 switches, depending on the specific patchset.
154 These are achieved by combination of
<a href=
"basictesting">local testing
</a>,
155 which includes mingw-w64 cross compilation and AppVeyor plus Travis-CI, the
156 latter two as part of their Github integration.
160 For Windows related changes, the main contact point is Brian
161 Paul. Jose Fonseca can also help as a fallback contact.
165 For Android related changes, the main contact is Tapani
166 P
älli. Mauro Rossi is collaborating with android-x86 and may
167 provide feedback about the build status in that project.
171 For MacOSX related changes, Jeremy Huddleston Sequoia is currently a
176 <strong>Note:
</strong> If a patch in the current queue needs any additional
177 fix(es), then they should be squashed together. The commit messages and the
178 "<code>cherry picked from
</code>"-tags must be preserved.
182 This should be noted in the
<a href=
"#prerelease">pre-announce
</a> email.
186 git show b10859ec41d09c57663a258f43fe57c12332698e
188 commit b10859ec41d09c57663a258f43fe57c12332698e
189 Author: Jonas Pfeil
<pfeiljonas@gmx.de
>
190 Date: Wed Mar
1 18:
11:
10 2017 +
0100
192 ralloc: Make sure ralloc() allocations match malloc()'s alignment.
194 The header of ralloc needs to be aligned, because the compiler assumes
197 (cherry picked from commit cd2b55e536dc806f9358f71db438dd9c246cdb14)
199 Squashed with commit:
201 ralloc: don't leave out the alignment factor
203 Experimentation shows that without alignment factor gcc and clang choose
206 (cherry picked from commit ff494fe999510ea40e3ed5827e7818550b6de126)
209 <h2>Regression/functionality testing
</h2>
212 Less often (once or twice), shortly before the pre-release announcement.
213 Ensure that testing is redone if Intel devs have requested an exception, as per above.
217 <li><em>no regressions should be observed for Piglit/dEQP/CTS/Vulkan on Intel platforms
</em>
218 <li><em>no regressions should be observed for Piglit using the swrast, softpipe
219 and llvmpipe drivers
</em>
223 Currently testing is performed courtesy of the Intel OTC team and their Jenkins CI setup. Check with the Intel team over IRC how to get things setup.
227 Installing the built driver from the pre-announced RC branch in the
228 system and making some every day's use until the release may be a good
232 <h2 id=
"stagingbranch">Staging branch
</h2>
235 A live branch, which contains the currently merge/rejected patches is available
236 in the main repository under
<code>staging/X.Y
</code>. For example:
239 staging/
18.1 - WIP branch for the
18.1 series
240 staging/
18.2 - WIP branch for the
18.2 series
247 <li>People are encouraged to test the staging branch and report regressions.
</li>
248 <li>The branch history is not stable and it
<strong>will
</strong> be rebased,
</li>
252 <h2 id=
"branch">Making a branchpoint
</h2>
255 A branchpoint is made such that new development can continue in parallel to
256 stabilisation and bugfixing.
260 Note: Before doing a branch ensure that basic build and
<code>meson test
</code>
261 testing is done and there are little to-no issues. Ideally all of those should
266 Check if the version number is going to remain as, alternatively
267 <code> git mv docs/relnotes/{current,new}.html
</code> as appropriate.
271 To setup the branchpoint:
274 git checkout master # make sure we're in master first
275 git tag -s X.Y-branchpoint -m
"Mesa X.Y branchpoint"
278 $EDITOR VERSION # bump the version number
280 cp docs/relnotes/{X.Y,X.Y+
1}.html # copy/create relnotes template
282 git push origin X.Y-branchpoint X.Y
287 <a href=
"https://gitlab.freedesktop.org/mesa/mesa/-/milestones" target=
"_parent">gitlab
</a> and add the new Mesa version X.Y.
291 Check that there are no distribution breaking changes and revert them if needed.
292 For example: files being overwritten on install, etc. Happens extremely rarely -
293 we had only one case so far (see commit
2ced8eb136528914e1bf4e000dea06a9d53c7e04).
297 Proceed to
<a href=
"#release">release
</a> -rc1.
301 <h2 id=
"prerelease">Pre-release announcement
</h2>
304 It comes shortly after outstanding patches in the respective branch are pushed.
305 Developers can check, in brief, what's the status of their patches. They,
306 alongside very early testers, are strongly encouraged to test the branch and
307 report any regressions.
310 It is followed by a brief period (normally
24 or
48 hours) before the actual
315 Be aware to add a note to warn about a final release in a series, if
319 <h2>Terminology used
</h2>
321 <ul><li>Nominated
</ul>
324 Patch that is nominated but yet to to merged in the patch queue/branch.
330 Patch is in the queue/branch and will feature in the next release.
331 Barring reported regressions or objections from developers.
334 <ul><li>Rejected
</ul>
337 Patch does not fit the
338 <a href=
"submittingpatches.html#criteria" target=
"_parent">criteria
</a> and
339 is followed by a brief information. The release maintainer is human so if you
340 believe you've spotted a mistake do let them know.
343 <h2>Format/template
</h2>
345 Subject: [ANNOUNCE] Mesa X.Y.Z release candidate
346 To: mesa-announce@...
351 The candidate for the Mesa X.Y.Z is now available. Currently we have:
353 - NUMBER nominated (outstanding)
354 - and NUMBER rejected patches
357 Note: this is the final anticipated release in the SERIES series. Users are
358 encouraged to migrate to the NEXT_SERIES series in order to obtain future fixes.]
360 BRIEF SUMMARY OF CHANGES
362 Take a look at section
"Mesa stable queue" for more information.
365 Testing reports/general approval
366 --------------------------------
367 Any testing reports (or general approval of the state of the branch) will be
370 The plan is to have X.Y.Z this DAY (DATE), around or shortly after TIME.
372 If you have any questions or suggestions - be that about the current patch
373 queue or otherwise, please go ahead.
376 Trivial merge conflicts
377 -----------------------
378 List of commits where manual intervention was required.
379 Keep the authors in the CC list.
391 commit
990f395e007c3204639daa34efc3049f350ee819
392 Author: Emil Velikov
<emil.velikov@collabora.com
>
394 anv: automake: cleanup the generated json file during make clean
396 (cherry picked from commit
8df581520a823564be0ab5af7dbb7d501b1c9670)
415 2de85eb radv: fix texturesamples to handle single sample case
430 ralloc: Make sure ralloc() allocations match malloc()'s alignment.
432 ralloc: don't leave out the alignment factor
446 a39ad18 configure.ac: honour LLVM_LIBDIR when linking against LLVM
448 Reason: The patch was reverted shortly after it was merged.
452 <h2 id=
"release">Making a new release
</h2>
455 These are the instructions for making a new Mesa release.
458 <h3>Get latest source files
</h3>
461 Ensure the latest code is available - both in your local master and the
465 <h3 id=
"basictesting">Perform basic testing
</h3>
468 Most of the testing should already be done during the
469 <a href=
"#pickntest">cherry-pick
</a> and
470 <a href=
"#prerelease">pre-announce
</a> stages.
471 So we do a quick 'touch test'
476 <li>scons (from release tarball)
477 <li>the produced binaries work
481 Here is one solution:
485 __glxgears_cmd='glxgears
2>&1 | grep -v
"configuration file"'
486 __es2info_cmd='es2_info
2>&1 | egrep
"GL_VERSION|GL_RENDERER|.*dri\.so"'
487 __es2gears_cmd='es2gears_x11
2>&1 | grep -v
"configuration file"'
488 test
"x$LD_LIBRARY_PATH" != 'x'
&& __old_ld=
"$LD_LIBRARY_PATH"
489 export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/:
"${__old_ld}"
490 export LIBGL_DRIVERS_PATH=`pwd`/test/usr/local/lib/dri/
491 export LIBGL_DEBUG=verbose
496 export LIBGL_ALWAYS_SOFTWARE=true
501 export LIBGL_ALWAYS_SOFTWARE=true
502 export GALLIUM_DRIVER=softpipe
508 unset LD_LIBRARY_PATH
509 test
"x$__old_ld" != 'x'
&& export
LD_LIBRARY_PATH=
"$__old_ld" && unset __old_ld
510 unset LIBGL_DRIVERS_PATH
512 unset LIBGL_ALWAYS_SOFTWARE
514 export VK_ICD_FILENAMES=`pwd`/test/usr/local/share/vulkan/icd.d/intel_icd.x86_64.json
515 steam steam://rungameid/
570 -vconsole -vulkan
516 unset VK_ICD_FILENAMES
519 <h3>Create release notes for the new release
</h3>
522 The release notes are completely generated by the
523 <pre>bin/gen_release_notes.py
</pre> script. Simply run this script before
526 The only thing left to do is add the sha256 sums.
529 <h3>Update version in file VERSION
</h3>
532 Increment the version contained in the file VERSION at Mesa's top-level, then
537 Commit these changes and push the branch.
545 <h3>Use the release.sh script from xorg
<a href=
"https://cgit.freedesktop.org/xorg/util/modular/">util-modular
</a></h3>
548 Start the release process.
552 # For the dist/distcheck, you may want to specify which LLVM to use:
553 # export LLVM_CONFIG=/usr/lib/llvm-
3.9/bin/llvm-config
554 ../relative/path/to/release.sh . # append --dist if you've already done distcheck above
558 Pay close attention to the prompts as you might be required to enter your GPG
559 and SSH passphrase(s) to sign and upload the files, respectively.
562 <h3>Add the sha256sums to the release notes
</h3>
565 Edit docs/relnotes/X.Y.Z.html to add the sha256sums as available in the mesa-X.Y.Z.announce template. Commit this change.
568 <h3>Back on mesa master, add the new release notes into the tree
</h3>
571 Something like the following steps will do the trick:
575 git cherry-pick -x X.Y~
1
576 git cherry-pick -x X.Y
579 <p>Then run the
<pre>./bin/post_verison.py X.Y.Z
</pre>, where X.Y.Z is the
580 version you just made. This will updated docs/relnotes.html and
581 docs/index.html. Remove docs/release-calendar.html. Then commit and push:
585 git commit -as -m
"docs: update calendar, add news item and link release notes for X.Y.Z"
586 git push origin master X.Y
590 <h2 id=
"announce">Announce the release
</h2>
593 Use the generated template during the releasing process.
597 Again, pay attention to add a note to warn about a final release in a
598 series, if that is the case.
602 <h2 id=
"gitlab">Update gitlab issues
</h2>
605 Parse through the bugreports as listed in the docs/relnotes/X.Y.Z.html
606 document. If there's outstanding action, close the bug referencing the commit
607 ID which addresses the bug and mention the Mesa version that has the fix.
611 Note: the above is not applicable to all the reports, so use common sense.