<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>
<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>
-<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>
For example:
</p>
<pre>
- Mesa 10.1.0 - 10.1 branch, feature
- Mesa 10.1.4 - 10.1 branch, bugfix
- Mesa 12.0.0 - 12.0 branch, feature
- Mesa 12.0.2 - 12.0 branch, bugfix
+Mesa 10.1.0 - 10.1 branch, feature
+Mesa 10.1.4 - 10.1 branch, bugfix
+Mesa 12.0.0 - 12.0 branch, feature
+Mesa 12.0.2 - 12.0 branch, bugfix
</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>The following must pass:</p>
<ul>
-<li>make distcheck, scons and scons check
+<li>meson test, scons and scons check
<li>Testing with different version of system components - LLVM and others is also
performed where possible.
<li>As a general rule, testing with various combinations of configure
<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>
<pre>
- git show b10859ec41d09c57663a258f43fe57c12332698e
+git show b10859ec41d09c57663a258f43fe57c12332698e
- commit b10859ec41d09c57663a258f43fe57c12332698e
- Author: Jonas Pfeil <pfeiljonas@gmx.de>
- Date: Wed Mar 1 18:11:10 2017 +0100
+commit b10859ec41d09c57663a258f43fe57c12332698e
+Author: Jonas Pfeil <pfeiljonas@gmx.de>
+Date: Wed Mar 1 18:11:10 2017 +0100
- ralloc: Make sure ralloc() allocations match malloc()'s alignment.
+ ralloc: Make sure ralloc() allocations match malloc()'s alignment.
- The header of ralloc needs to be aligned, because the compiler assumes
- ...
+ The header of ralloc needs to be aligned, because the compiler assumes
+ ...
- (cherry picked from commit cd2b55e536dc806f9358f71db438dd9c246cdb14)
+ (cherry picked from commit cd2b55e536dc806f9358f71db438dd9c246cdb14)
- Squashed with commit:
+ Squashed with commit:
- ralloc: don't leave out the alignment factor
+ ralloc: don't leave out the alignment factor
- Experimentation shows that without alignment factor gcc and clang choose
- ...
+ Experimentation shows that without alignment factor gcc and clang choose
+ ...
- (cherry picked from commit ff494fe999510ea40e3ed5827e7818550b6de126)
+ (cherry picked from commit ff494fe999510ea40e3ed5827e7818550b6de126)
</pre>
<h2>Regression/functionality testing</h2>
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
in the main repository under <code>staging/X.Y</code>. For example:
</p>
<pre>
- staging/18.1 - WIP branch for the 18.1 series
- staging/18.2 - WIP branch for the 18.2 series
+staging/18.1 - WIP branch for the 18.1 series
+staging/18.2 - WIP branch for the 18.2 series
</pre>
<p>
</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>
<p>
-Note: Before doing a branch ensure that basic build and <code>make check</code>
-testing is done and there are little to-no issues.
-<br>
-Ideally all of those should be tackled already.
+Note: Before doing a branch ensure that basic build and <code>meson test</code>
+testing is done and there are little to-no issues. Ideally all of those should
+be tackled already.
</p>
<p>
To setup the branchpoint:
</p>
<pre>
- git checkout master # make sure we're in master first
- git tag -s X.Y-branchpoint -m "Mesa X.Y branchpoint"
- git checkout -b X.Y
- git checkout master
- $EDITOR VERSION # bump the version number
- git commit -as
- cp docs/relnotes/{X.Y,X.Y+1}.html # copy/create relnotes template
- git commit -as
- git push origin X.Y-branchpoint X.Y
+git checkout master # make sure we're in master first
+git tag -s X.Y-branchpoint -m "Mesa X.Y branchpoint"
+git checkout -b X.Y
+git checkout master
+$EDITOR VERSION # bump the version number
+git commit -as
+cp docs/relnotes/{X.Y,X.Y+1}.html # copy/create relnotes template
+git commit -as
+git push origin X.Y-branchpoint X.Y
</pre>
<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.
</p>
<pre>
- __glxgears_cmd='glxgears 2>&1 | grep -v "configuration file"'
- __es2info_cmd='es2_info 2>&1 | egrep "GL_VERSION|GL_RENDERER|.*dri\.so"'
- __es2gears_cmd='es2gears_x11 2>&1 | grep -v "configuration file"'
- test "x$LD_LIBRARY_PATH" != 'x' && __old_ld="$LD_LIBRARY_PATH"
- export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/:"${__old_ld}"
- export LIBGL_DRIVERS_PATH=`pwd`/test/usr/local/lib/dri/
- export LIBGL_DEBUG=verbose
- eval $__glxinfo_cmd
- eval $__glxgears_cmd
- eval $__es2info_cmd
- eval $__es2gears_cmd
- export LIBGL_ALWAYS_SOFTWARE=true
- eval $__glxinfo_cmd
- eval $__glxgears_cmd
- eval $__es2info_cmd
- eval $__es2gears_cmd
- export LIBGL_ALWAYS_SOFTWARE=true
- export GALLIUM_DRIVER=softpipe
- eval $__glxinfo_cmd
- eval $__glxgears_cmd
- eval $__es2info_cmd
- eval $__es2gears_cmd
- # Smoke test DOTA2
- unset LD_LIBRARY_PATH
- test "x$__old_ld" != 'x' && export LD_LIBRARY_PATH="$__old_ld" && unset __old_ld
- unset LIBGL_DRIVERS_PATH
- unset LIBGL_DEBUG
- unset LIBGL_ALWAYS_SOFTWARE
- unset GALLIUM_DRIVER
- export VK_ICD_FILENAMES=`pwd`/src/intel/vulkan/dev_icd.json
- steam steam://rungameid/570 -vconsole -vulkan
- unset VK_ICD_FILENAMES
+__glxgears_cmd='glxgears 2>&1 | grep -v "configuration file"'
+__es2info_cmd='es2_info 2>&1 | egrep "GL_VERSION|GL_RENDERER|.*dri\.so"'
+__es2gears_cmd='es2gears_x11 2>&1 | grep -v "configuration file"'
+test "x$LD_LIBRARY_PATH" != 'x' && __old_ld="$LD_LIBRARY_PATH"
+export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/:"${__old_ld}"
+export LIBGL_DRIVERS_PATH=`pwd`/test/usr/local/lib/dri/
+export LIBGL_DEBUG=verbose
+eval $__glxinfo_cmd
+eval $__glxgears_cmd
+eval $__es2info_cmd
+eval $__es2gears_cmd
+export LIBGL_ALWAYS_SOFTWARE=true
+eval $__glxinfo_cmd
+eval $__glxgears_cmd
+eval $__es2info_cmd
+eval $__es2gears_cmd
+export LIBGL_ALWAYS_SOFTWARE=true
+export GALLIUM_DRIVER=softpipe
+eval $__glxinfo_cmd
+eval $__glxgears_cmd
+eval $__es2info_cmd
+eval $__es2gears_cmd
+# Smoke test DOTA2
+unset LD_LIBRARY_PATH
+test "x$__old_ld" != 'x' && export LD_LIBRARY_PATH="$__old_ld" && unset __old_ld
+unset LIBGL_DRIVERS_PATH
+unset LIBGL_DEBUG
+unset LIBGL_ALWAYS_SOFTWARE
+unset GALLIUM_DRIVER
+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
+<code>bin/gen_release_notes.py</code> 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>
</p>
<pre>
- git push origin HEAD
+git push origin HEAD
</pre>
</p>
<pre>
- # For the dist/distcheck, you may want to specify which LLVM to use:
- # export LLVM_CONFIG=/usr/lib/llvm-3.9/bin/llvm-config
- ../relative/path/to/release.sh . # append --dist if you've already done distcheck above
+# For the dist/distcheck, you may want to specify which LLVM to use:
+# export LLVM_CONFIG=/usr/lib/llvm-3.9/bin/llvm-config
+../relative/path/to/release.sh . # append --dist if you've already done distcheck above
</pre>
<p>
</p>
<pre>
- git cherry-pick -x X.Y~1
- git cherry-pick -x X.Y
+git cherry-pick -x X.Y~1
+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 <code>./bin/post_verison.py X.Y.Z</code>, 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>
- git commit -as -m "docs: update calendar, add news item and link release notes for X.Y.Z"
- git push origin master X.Y
+git commit -as -m "docs: update calendar, add news item and link release notes for X.Y.Z"
+git push origin master X.Y
</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>
-
-<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>
-
-
-<h1 id="bugzilla">Update Bugzilla</h1>
+<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>
projects / mesa.git / blobdiff