<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="#schedule">Release schedule</a>
<li><a href="#pickntest">Cherry-pick and test</a>
+<li><a href="#stagingbranch">Staging branch</a>
<li><a href="#branch">Making a branchpoint</a>
<li><a href="#prerelease">Pre-release announcement</a>
<li><a href="#release">Making a new release</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 keep to a minimum.
-<br>
-See our <a href="release-calendar.html" target="_parent">calendar</a> for the
+should be kept to a minimum.
+</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>
<li>Available approximately every three months.
<li>Initial timeplan available 2-4 weeks before the planned branchpoint (rc1)
on the mesa-announce@ mailing list.
+<li>Typically, the final release will happen after 4
+candidates. Additional ones may be needed in order to resolve blocking
+regressions, though.
<li>A <a href="#prerelease">pre-release</a> announcement should be available
approximately 24 hours before the final (non-rc) release.
</ul>
<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.
</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
+the <a href="release-calendar.html" target="_parent">calendar</a> with
+additional bug fix releases of the current stable branch.
+</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>Done continuously up-to the <a href="#prerelease">pre-release</a> announcement.</p>
<p>
-As an exception, patches can be applied up-to the last ~1h before the actual
-release. This is made <strong>only</strong> with explicit permission/request,
-and the patch <strong>must</strong> be very well contained. Thus it cannot
-affect more than one driver/subsystem.
+Developers can request, <em>as an exception</em>, patches to be applied up-to
+the last one hour before the actual release. This is made <strong>only</strong>
+with explicit permission/request, and the patch <strong>must</strong> be very
+well contained. Thus it cannot affect more than one driver/subsystem.
</p>
-<p>
-Currently Ilia Mirkin and AMD devs have requested "permanent" exception.
-</p>
+<p>Following developers have requested permanent exception</p>
+<ul>
+<li><em>Ilia Mirkin</em>
+<li><em>AMD team</em>
+</ul>
+<p>The following must pass:</p>
<ul>
-<li>make distcheck, scons and scons check must pass
+<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
</ul>
<p>
-Achieved by combination of local ad-hoc scripts, mingw-w64 cross
-compilation and AppVeyor plus Travis-CI, the latter as part of their
-Github integration.
+These are achieved by combination of <a href="basictesting">local testing</a>,
+which includes mingw-w64 cross compilation and AppVeyor plus Travis-CI, the
+latter two as part of their Github integration.
</p>
<p>
<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>
+<h2 id="stagingbranch">Staging branch</h2>
-<h1 id="branch">Making a branchpoint</h1>
+<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
+</pre>
+
+<p>
+Notes:
+</p>
+<ul>
+<li>People are encouraged to test the staging branch and report regressions.</li>
+<li>The branch history is not stable and it <strong>will</strong> be rebased,</li>
+</ul>
+
+
+<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>
</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.
relevant branch.
</p>
-<h3>Perform basic testing</h3>
+<h3 id="basictesting">Perform basic testing</h3>
<p>
Most of the testing should already be done during the
</p>
<ul>
-<li>make distcheck (you can omit this if you're not using --dist below)
+<li>meson dist
<li>scons (from release tarball)
<li>the produced binaries work
</ul>
<p>
-Here is one solution that I've been using.
+ Here is one solution:
</p>
<pre>
- # Set MAKEFLAGS if you haven't already
- git clean -fXd; git clean -nxd
- read # quick cross check any outstanding files
- export __version=`cat VERSION`
- export __mesa_root=../
- export __build_root=./foo
- chmod 755 -fR $__build_root; rm -rf $__build_root
- mkdir -p $__build_root && cd $__build_root
-
- # For the native builds - such as distcheck, scons, sanity test, you
- # may want to specify which LLVM to use:
- # export LLVM_CONFIG=/usr/lib/llvm-3.9/bin/llvm-config
-
- # Do a full distcheck
- $__mesa_root/autogen.sh && make distcheck
-
- # Build check the tarballs (scons, linux)
- tar -xaf mesa-$__version.tar.xz && cd mesa-$__version
- scons
- cd .. && rm -rf mesa-$__version
-
- # Build check the tarballs (scons, windows/mingw)
- # Temporary drop LLVM_CONFIG, unless you have a Windows/mingw one.
- # save_LLVM_CONFIG=`echo $LLVM_CONFIG`; unset LLVM_CONFIG
- tar -xaf mesa-$__version.tar.xz && cd mesa-$__version
- scons platform=windows toolchain=crossmingw
- cd .. && rm -rf mesa-$__version
-
- # Test the automake binaries
- # Restore LLVM_CONFIG, if applicable:
- # export LLVM_CONFIG=`echo $save_LLVM_CONFIG`; unset save_LLVM_CONFIG
- tar -xaf mesa-$__version.tar.xz && cd mesa-$__version
- ./configure \
- --with-dri-drivers=i965,swrast \
- --with-gallium-drivers=swrast \
- --with-vulkan-drivers=intel \
- --enable-llvm-shared-libs \
- --enable-llvm \
- --enable-glx-tls \
- --enable-gbm \
- --enable-egl \
- --with-platforms=x11,drm,wayland,surfaceless
- make && DESTDIR=`pwd`/test make install
-
- # Drop LLVM_CONFIG, if applicable:
- # unset LLVM_CONFIG
-
- __glxinfo_cmd='glxinfo 2>&1 | egrep -o "Mesa.*|Gallium.*|.*dri\.so"'
- __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`/src/intel/vulkan/dev_icd.json
+ steam steam://rungameid/570 -vconsole -vulkan
+ unset VK_ICD_FILENAMES
</pre>
<h3>Update version in file VERSION</h3>
</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