Releasing Process
=================
-- `Overview <#overview>`__
-- `Release schedule <#schedule>`__
-- `Cherry-pick and test <#pickntest>`__
-- `Staging branch <#stagingbranch>`__
-- `Making a branchpoint <#branch>`__
-- `Making a new release <#release>`__
-- `Announce the release <#announce>`__
-- `Update Gitlab Issues <#gitlab>`__
-
Overview
--------
Releases should happen on Wednesdays. Delays can occur although those
should be kept to a minimum.
-See our `calendar <release-calendar.html>`__ for information about how
+See our :doc:`calendar <release-calendar>` for information about how
the release schedule is planned, and the date and other details for
individual releases.
- Normally available once every two weeks.
- Only the latest branch has releases. See note below.
-Note: There is one or two releases overlap when changing branches. For
-example:
+.. note::
+
+ There is one or two releases overlap when changing branches. For
+ example:
-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.
+ 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.
-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
-`calendar <release-calendar.html>`__ with additional bug fix releases of
-the current stable branch.
+ 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
+ :doc:`calendar <release-calendar>` with additional bug fix releases of
+ the current stable branch.
.. _pickntest:
--------------------------
Commits nominated for the active branch are picked as based on the
-`criteria <submittingpatches.html#criteria>`__ as described in the same
+:ref:`criteria <criteria>` as described in the same
section.
Nominations happen via special tags in the commit messages, and via
For MacOSX related changes, Jeremy Huddleston Sequoia is currently a
good contact point.
-**Note:** If a patch in the current queue needs any additional fix(es),
-then they should be squashed together. The commit messages and the
-"``cherry picked from``"-tags must be preserved.
+.. note::
+
+ If a patch in the current queue needs any additional fix(es),
+ then they should be squashed together. The commit messages and the
+ "``cherry picked from``"-tags must be preserved.
::
regressions.
- The branch history is not stable and it **will** be rebased,
-.. _branch:
-
Making a branchpoint
--------------------
A branchpoint is made such that new development can continue in parallel
to stabilisation and bugfixing.
-Note: Before doing a branch ensure that basic build and ``meson test``
-testing is done and there are little to-no issues. Ideally all of those
-should be tackled already.
+.. note::
+
+ Before doing a branch ensure that basic build and ``meson test``
+ testing is done and there are little to-no issues. Ideally all of those
+ should be tackled already.
Check if the version number is going to remain as, alternatively
-``git mv docs/relnotes/{current,new}.html`` as appropriate.
+``git mv docs/relnotes/{current,new}.rst`` as appropriate.
To setup the branchpoint:
extremely rarely - we had only one case so far (see commit
2ced8eb136528914e1bf4e000dea06a9d53c7e04).
-.. _release:
-
Making a new release
--------------------
Ensure the latest code is available - both in your local master and the
relevant branch.
-.. _basictesting:
-
Perform basic testing
~~~~~~~~~~~~~~~~~~~~~
Most of the testing should already be done during the
-`cherry-pick <#pickntest>`__ So we do a quick 'touch test'
+:ref:`cherry-pick <pickntest>` So we do a quick 'touch test'
- meson dist
- scons (from release tarball)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The release notes are completely generated by the
-``bin/gen_release_notes.py`` script. Simply run this script before
-bumping the version, and commit the results. The only thing left to do
-is add the sha256 sums.
-
-Increment the version contained in the file VERSION at Mesa's top-level,
-then commit this change.
+``bin/gen_release_notes.py`` script. Simply run this script **before**
+bumping the version. You'll need to come back to this file once the
+tarball is generated to add its ``sha256sum``.
-Commit these changes and push the branch.
-
-::
-
- git push origin HEAD
+Increment the version contained in the file ``VERSION`` at Mesa's top-level,
+then commit this change and **push the branch** (if you forget to do
+this, ``release.sh`` below will fail).
Use the release.sh script from xorg `util-modular <https://cgit.freedesktop.org/xorg/util/modular/>`__
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
your GPG and SSH passphrase(s) to sign and upload the files,
respectively.
+Ensure that you do sign the tarballs, that your key is mentioned in the
+release notes, and is published in `release-maintainers-keys.asc
+<release-maintainers-keys.asc>`__.
+
+
Add the sha256sums to the release notes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Edit docs/relnotes/X.Y.Z.html to add the sha256sum as available in the
-mesa-X.Y.Z.announce template. Commit this change.
+Edit ``docs/relnotes/X.Y.Z.rst`` to add the ``sha256sum`` as available in the
+``mesa-X.Y.Z.announce`` template. Commit this change.
Back on mesa master, add the new release notes into the tree
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./bin/post_version.py X.Y.Z
-, where X.Y.Z is the version you just made. This will updated
-docs/relnotes.html, docs/index.html, and docs/release-calendar.html. It
-will then generate a git commit automatically. Check that everything
-looks correct and push:
+, where X.Y.Z is the version you just made. This will update
+docs/relnotes.rst and docs/release-calendar.rst. It will then generate
+a git commit automatically. Check that everything looks correct and
+push:
::
git push origin master X.Y
-.. _announce:
-
Announce the release
--------------------
Again, pay attention to add a note to warn about a final release in a
series, if that is the case.
-.. _gitlab:
-
Update gitlab issues
--------------------
-Parse through the bug reports as listed in the docs/relnotes/X.Y.Z.html
+Parse through the bug reports as listed in the docs/relnotes/X.Y.Z.rst
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.
-Note: the above is not applicable to all the reports, so use common
-sense.
+.. note: the above is not applicable to all the reports, so use common sense.
projects / mesa.git / blobdiff