<li><a href="#prerelease">Pre-release announcement</a>
<li><a href="#release">Making a new release</a>
<li><a href="#announce">Announce the release</a>
-<li><a href="#website">Update the mesa3d.org website</a>
-<li><a href="#bugzilla">Update Bugzilla</a>
+<li><a href="#gitlab">Update Gitlab Issues</a>
</ul>
<p>
This document uses the convention X.Y.Z for the release number with X.Y being
the stable branch name.
-<br>
+</p>
+
+<p>
Mesa provides feature and bugfix releases. Former use zero as patch version (Z),
while the latter have a non-zero one.
</p>
<p>
Releases should happen on Wednesdays. Delays can occur although those
should be kept to a minimum.
-<br>
+</p>
+
+<p>
See our <a href="release-calendar.html" target="_parent">calendar</a>
for information about how the release schedule is planned, and the
date and other details for individual releases.
<p>
Note: There is one or two releases overlap when changing branches. For example:
-<br>
+</p>
+
+<p>
The final release from the 12.0 series Mesa 12.0.5 will be out around the same
time (or shortly after) 13.0.1 is out.
-<br>
+</p>
+
+<p>
This also involves that, as a final release may be delayed due to the
need of additional candidates to solve some blocking regression(s),
the release manager might have to update
<p>
Maintainer is also responsible for testing in various possible permutations of
-the autoconf and scons build.
+the meson and scons build.
</p>
<h2>Cherry-picking and build/check testing</h2>
<p>
<strong>Note:</strong> If a patch in the current queue needs any additional
-fix(es), then they should be squashed together.
-<br>
-The commit messages and the <code>cherry picked from</code> tags must be preserved.
+fix(es), then they should be squashed together. The commit messages and the
+"<code>cherry picked from</code>"-tags must be preserved.
</p>
<p>
<p>
Note: Before doing a branch ensure that basic build and <code>meson test</code>
-testing is done and there are little to-no issues.
-<br>
-Ideally all of those should be tackled already.
+testing is done and there are little to-no issues. Ideally all of those should
+be tackled already.
</p>
<p>
<p>
Now go to
-<a href="https://bugs.freedesktop.org/editversions.cgi?action=add&product=Mesa" target="_parent">Bugzilla</a> and add the new Mesa version X.Y.
+<a href="https://gitlab.freedesktop.org/mesa/mesa/-/milestones" target="_parent">gitlab</a> and add the new Mesa version X.Y.
</p>
<p>
Developers can check, in brief, what's the status of their patches. They,
alongside very early testers, are strongly encouraged to test the branch and
report any regressions.
-<br>
+</p>
+<p>
It is followed by a brief period (normally 24 or 48 hours) before the actual
release is made.
</p>
<p>
Patch does not fit the
<a href="submittingpatches.html#criteria" target="_parent">criteria</a> and
-is followed by a brief information.
-<br>
-The release maintainer is human so if you believe you've spotted a mistake do
-let them know.
+is followed by a brief information. The release maintainer is human so if you
+believe you've spotted a mistake do let them know.
</p>
<h2>Format/template</h2>
unset LIBGL_DEBUG
unset LIBGL_ALWAYS_SOFTWARE
unset GALLIUM_DRIVER
- export VK_ICD_FILENAMES=`pwd`/src/intel/vulkan/dev_icd.json
+ export VK_ICD_FILENAMES=`pwd`/test/usr/local/share/vulkan/icd.d/intel_icd.x86_64.json
steam steam://rungameid/570 -vconsole -vulkan
unset VK_ICD_FILENAMES
</pre>
-<h3>Update version in file VERSION</h3>
-
-<p>
-Increment the version contained in the file VERSION at Mesa's top-level, then
-commit this change.
-</p>
-
<h3>Create release notes for the new release</h3>
<p>
-Create a new file docs/relnotes/X.Y.Z.html, (follow the style of the previous
-release notes). Note that the sha256sums section of the release notes should
-be empty (TBD) at this point.
-</p>
+The release notes are completely generated by the
+<pre>bin/gen_release_notes.py</pre> script. Simply run this script before
+bumping the version
-<p>
-Two scripts are available to help generate portions of the release notes:
+The only thing left to do is add the sha256 sums.
</p>
-<pre>
- ./bin/bugzilla_mesa.sh
- ./bin/shortlog_mesa.sh
-</pre>
+<h3>Update version in file VERSION</h3>
<p>
-The first script identifies commits that reference bugzilla bugs and obtains
-the descriptions of those bugs from bugzilla. The second script generates a
-log of all commits. In both cases, HTML-formatted lists are printed to stdout
-to be included in the release notes.
+Increment the version contained in the file VERSION at Mesa's top-level, then
+commit this change.
</p>
<p>
git cherry-pick -x X.Y
</pre>
-<p>
-Also, edit docs/relnotes.html to add a link to the new release notes,
-edit docs/index.html to add a news entry and a note in case of the
-last release in a series, and remove the version from
-docs/release-calendar.html. Then commit and push:
+<p>Then run the <pre>./bin/post_verison.py X.Y.Z</pre>, where X.Y.Z is the
+version you just made. This will updated docs/relnotes.html and
+docs/index.html. Remove docs/release-calendar.html. Then commit and push:
</p>
<pre>
</p>
-<h2 id="website">Update the mesa3d.org website</h2>
-
-<p>
-As the hosting was moved to freedesktop, git hooks are deployed to update the
-website. Manually check that it is updated 5-10 minutes after the final <code>git push</code>
-</p>
-
-
-<h2 id="bugzilla">Update Bugzilla</h2>
+<h2 id="gitlab">Update gitlab issues</h2>
<p>
Parse through the bugreports as listed in the docs/relnotes/X.Y.Z.html
-document.
-<br>
-If there's outstanding action, close the bug referencing the commit ID which
-addresses the bug and mention the Mesa version that has the fix.
+document. If there's outstanding action, close the bug referencing the commit
+ID which addresses the bug and mention the Mesa version that has the fix.
</p>
<p>