7 This document uses the convention X.Y.Z for the release number with X.Y
8 being the stable branch name.
10 Mesa provides feature and bugfix releases. Former use zero as patch
11 version (Z), while the latter have a non-zero one.
17 Mesa 10.1.0 - 10.1 branch, feature
18 Mesa 10.1.4 - 10.1 branch, bugfix
19 Mesa 12.0.0 - 12.0 branch, feature
20 Mesa 12.0.2 - 12.0 branch, bugfix
27 Releases should happen on Wednesdays. Delays can occur although those
28 should be kept to a minimum.
30 See our :doc:`calendar <release-calendar>` for information about how
31 the release schedule is planned, and the date and other details for
37 - Available approximately every three months.
38 - Initial timeplan available 2-4 weeks before the planned branchpoint
39 (rc1) on the mesa-announce@ mailing list.
40 - Typically, the final release will happen after 4 candidates.
41 Additional ones may be needed in order to resolve blocking
47 - Normally available once every two weeks.
48 - Only the latest branch has releases. See note below.
52 There is one or two releases overlap when changing branches. For
55 The final release from the 12.0 series Mesa 12.0.5 will be out around
56 the same time (or shortly after) 13.0.1 is out.
58 This also involves that, as a final release may be delayed due to the
59 need of additional candidates to solve some blocking regression(s), the
60 release manager might have to update the
61 :doc:`calendar <release-calendar>` with additional bug fix releases of
62 the current stable branch.
66 Cherry-picking and testing
67 --------------------------
69 Commits nominated for the active branch are picked as based on the
70 :ref:`criteria <criteria>` as described in the same
73 Nominations happen via special tags in the commit messages, and via
74 gitlab merge requests against the staging branches. There are special
75 scripts used to read the tags.
77 The maintainer should watch or be in contact with the Intel CI team, as
78 well as watch the gitlab CI for regressions.
80 Cherry picking should be done with the '-x' switch (to automatically add
81 "cherry picked from ..." to the commit message):
83 ``git cherry-pick -x abcdef12345667890``
85 Developers can request, *as an exception*, patches to be applied up-to
86 the last one hour before the actual release. This is made **only** with
87 explicit permission/request, and the patch **must** be very well
88 contained. Thus it cannot affect more than one driver/subsystem.
90 Following developers have requested permanent exception
95 The gitlab CI must pass.
97 For Windows related changes, the main contact point is Brian Paul. Jose
98 Fonseca can also help as a fallback contact.
100 For Android related changes, the main contact is Tapani Pälli. Mauro
101 Rossi is collaborating with android-x86 and may provide feedback about
102 the build status in that project.
104 For MacOSX related changes, Jeremy Huddleston Sequoia is currently a
109 If a patch in the current queue needs any additional fix(es),
110 then they should be squashed together. The commit messages and the
111 "``cherry picked from``"-tags must be preserved.
115 git show b10859ec41d09c57663a258f43fe57c12332698e
117 commit b10859ec41d09c57663a258f43fe57c12332698e
118 Author: Jonas Pfeil <pfeiljonas@gmx.de>
119 Date: Wed Mar 1 18:11:10 2017 +0100
121 ralloc: Make sure ralloc() allocations match malloc()'s alignment.
123 The header of ralloc needs to be aligned, because the compiler assumes
126 (cherry picked from commit cd2b55e536dc806f9358f71db438dd9c246cdb14)
128 Squashed with commit:
130 ralloc: don't leave out the alignment factor
132 Experimentation shows that without alignment factor gcc and clang choose
135 (cherry picked from commit ff494fe999510ea40e3ed5827e7818550b6de126)
137 Regression/functionality testing
138 --------------------------------
140 - *no regressions should be observed for Piglit/dEQP/CTS/Vulkan on
142 - *no regressions should be observed for Piglit using the swrast,
143 softpipe and llvmpipe drivers*
150 A live branch, which contains the currently merge/rejected patches is
151 available in the main repository under ``staging/X.Y``. For example:
155 staging/18.1 - WIP branch for the 18.1 series
156 staging/18.2 - WIP branch for the 18.2 series
160 - People are encouraged to test the staging branch and report
162 - The branch history is not stable and it **will** be rebased,
167 A branchpoint is made such that new development can continue in parallel
168 to stabilisation and bugfixing.
172 Before doing a branch ensure that basic build and ``meson test``
173 testing is done and there are little to-no issues. Ideally all of those
174 should be tackled already.
176 Check if the version number is going to remain as, alternatively
177 ``git mv docs/relnotes/{current,new}.rst`` as appropriate.
179 To setup the branchpoint:
183 git checkout master # make sure we're in master first
184 git tag -s X.Y-branchpoint -m "Mesa X.Y branchpoint"
187 $EDITOR VERSION # bump the version number
189 truncate docs/relnotes/new_features.txt
191 git push origin X.Y-branchpoint X.Y
194 `gitlab <https://gitlab.freedesktop.org/mesa/mesa/-/milestones>`__ and
195 add the new Mesa version X.Y.
197 Check that there are no distribution breaking changes and revert them if
198 needed. For example: files being overwritten on install, etc. Happens
199 extremely rarely - we had only one case so far (see commit
200 2ced8eb136528914e1bf4e000dea06a9d53c7e04).
205 These are the instructions for making a new Mesa release.
207 Get latest source files
208 ~~~~~~~~~~~~~~~~~~~~~~~
210 Ensure the latest code is available - both in your local master and the
213 Perform basic testing
214 ~~~~~~~~~~~~~~~~~~~~~
216 Most of the testing should already be done during the
217 :ref:`cherry-pick <pickntest>` So we do a quick 'touch test'
220 - scons (from release tarball)
221 - the produced binaries work
223 Here is one solution:
227 __glxgears_cmd='glxgears 2>&1 | grep -v "configuration file"'
228 __es2info_cmd='es2_info 2>&1 | egrep "GL_VERSION|GL_RENDERER|.*dri\.so"'
229 __es2gears_cmd='es2gears_x11 2>&1 | grep -v "configuration file"'
230 test "x$LD_LIBRARY_PATH" != 'x' && __old_ld="$LD_LIBRARY_PATH"
231 export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/:"${__old_ld}"
232 export LIBGL_DRIVERS_PATH=`pwd`/test/usr/local/lib/dri/
233 export LIBGL_DEBUG=verbose
238 export LIBGL_ALWAYS_SOFTWARE=true
243 export LIBGL_ALWAYS_SOFTWARE=true
244 export GALLIUM_DRIVER=softpipe
250 unset LD_LIBRARY_PATH
251 test "x$__old_ld" != 'x' && export LD_LIBRARY_PATH="$__old_ld" && unset __old_ld
252 unset LIBGL_DRIVERS_PATH
254 unset LIBGL_ALWAYS_SOFTWARE
256 export VK_ICD_FILENAMES=`pwd`/test/usr/local/share/vulkan/icd.d/intel_icd.x86_64.json
257 steam steam://rungameid/570 -vconsole -vulkan
258 unset VK_ICD_FILENAMES
260 Create release notes for the new release
261 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
263 The release notes are completely generated by the
264 ``bin/gen_release_notes.py`` script. Simply run this script **before**
265 bumping the version. You'll need to come back to this file once the
266 tarball is generated to add its ``sha256sum``.
268 Increment the version contained in the file ``VERSION`` at Mesa's top-level,
269 then commit this change and **push the branch** (if you forget to do
270 this, ``release.sh`` below will fail).
272 Use the release.sh script from xorg `util-modular <https://cgit.freedesktop.org/xorg/util/modular/>`__
273 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
275 Start the release process.
279 ../relative/path/to/release.sh . # append --dist if you've already done distcheck above
281 Pay close attention to the prompts as you might be required to enter
282 your GPG and SSH passphrase(s) to sign and upload the files,
285 Ensure that you do sign the tarballs, that your key is mentioned in the
286 release notes, and is published in `release-maintainers-keys.asc
287 <release-maintainers-keys.asc>`__.
290 Add the sha256sums to the release notes
291 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
293 Edit ``docs/relnotes/X.Y.Z.rst`` to add the ``sha256sum`` as available in the
294 ``mesa-X.Y.Z.announce`` template. Commit this change.
296 Back on mesa master, add the new release notes into the tree
297 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
299 Something like the following steps will do the trick:
303 git cherry-pick -x X.Y~1
304 git cherry-pick -x X.Y
310 ./bin/post_version.py X.Y.Z
312 , where X.Y.Z is the version you just made. This will update
313 docs/relnotes.rst and docs/release-calendar.rst. It will then generate
314 a git commit automatically. Check that everything looks correct and
319 git push origin master X.Y
324 Use the generated template during the releasing process.
326 Again, pay attention to add a note to warn about a final release in a
327 series, if that is the case.
332 Parse through the bug reports as listed in the docs/relnotes/X.Y.Z.rst
333 document. If there's outstanding action, close the bug referencing the
334 commit ID which addresses the bug and mention the Mesa version that has
337 .. note: the above is not applicable to all the reports, so use common sense.