<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
- <title>Releasing process</title>
+ <title>Releasing Process</title>
<link rel="stylesheet" type="text/css" href="mesa.css">
</head>
<body>
<div class="header">
- <h1>The Mesa 3D Graphics Library</h1>
+ The Mesa 3D Graphics Library
</div>
<iframe src="contents.html"></iframe>
<div class="content">
-<h1>Releasing process</h1>
+<h1>Releasing Process</h1>
<ul>
<li><a href="#overview">Overview</a>
</ul>
-<h1 id="overview">Overview</h1>
+<h2 id="overview">Overview</h2>
<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>
</pre>
-<h1 id="schedule">Release schedule</h1>
+<h2 id="schedule">Release schedule</h2>
<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>
-<h1 id="pickntest">Cherry-picking and testing</h1>
+<h2 id="pickntest">Cherry-picking and testing</h2>
<p>
Commits nominated for the active branch are picked as based on the
<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>
idea too.
</p>
-<h1 id="stagingbranch">Staging branch</h1>
+<h2 id="stagingbranch">Staging branch</h2>
<p>
A live branch, which contains the currently merge/rejected patches is available
</ul>
-<h1 id="branch">Making a branchpoint</h1>
+<h2 id="branch">Making a branchpoint</h2>
<p>
A branchpoint is made such that new development can continue in parallel to
<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>
</p>
-<h1 id="prerelease">Pre-release announcement</h1>
+<h2 id="prerelease">Pre-release announcement</h2>
<p>
It comes shortly after outstanding patches in the respective branch are pushed.
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>
</pre>
-<h1 id="release">Making a new release</h1>
+<h2 id="release">Making a new release</h2>
<p>
These are the instructions for making a new Mesa release.
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>
</pre>
-<h1 id="announce">Announce the release</h1>
+<h2 id="announce">Announce the release</h2>
<p>
Use the generated template during the releasing process.
</p>
-<h1 id="website">Update the mesa3d.org website</h1>
+<h2 id="website">Update the mesa3d.org website</h2>
<p>
As the hosting was moved to freedesktop, git hooks are deployed to update the
</p>
-<h1 id="bugzilla">Update Bugzilla</h1>
+<h2 id="bugzilla">Update Bugzilla</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>
projects / mesa.git / blobdiff