Lines Matching defs:the
7 This document uses the convention X.Y.Z for the release number with X.Y
8 being the stable branch name.
11 version (Z), while the latter have a non-zero one.
31 the release schedule is planned, and the date and other details for
38 - Feature releases are branched on or around the second Wednesday of
40 - Initial time plan available 2-4 weeks before the planned branchpoint
41 (rc1) on the mesa-announce@ mailing list.
42 - Typically, the final release will happen after 4 candidates.
50 - Only the latest branch has releases. See note below.
57 The final release from the 12.0 series Mesa 12.0.5 will be out around
58 the same time (or shortly after) 13.0.1 is out.
60 This also involves that, as a final release may be delayed due to the
61 need of additional candidates to solve some blocking regression(s), the
62 release manager might have to update the
64 the current stable branch.
71 Commits nominated for the active branch are picked as based on the
72 :ref:`criteria <criteria>` as described in the same
75 Nominations happen via special tags in the commit messages, and via
76 GitLab merge requests against the staging branches. There are special
77 scripts used to read the tags.
79 The maintainer should watch or be in contact with the Intel CI team, as
80 well as watch the GitLab CI for regressions.
82 Cherry picking should be done with the '-x' switch (to automatically add
83 "cherry picked from ..." to the commit message):
88 the last one hour before the actual release. This is made **only** with
89 explicit permission/request, and the patch **must** be very well
99 For Windows related changes, the main contact point is Brian Paul. Jose
102 For Android related changes, the main contact is Tapani Pälli. Mauro
104 the build status in that project.
111 If a patch in the current queue needs any additional fix(es),
112 then they should be squashed together. The commit messages and the
125 The header of ralloc needs to be aligned, because the compiler assumes
132 ralloc: don't leave out the alignment factor
144 - *no regressions should be observed for Piglit using the swrast,
152 A live branch, which contains the currently merge/rejected patches is
153 available in the main repository under ``staging/X.Y``. For example:
157 staging/18.1 - WIP branch for the 18.1 series
158 staging/18.2 - WIP branch for the 18.2 series
162 - People are encouraged to test the staging branch and report
178 Check if the version number is going to remain as, alternatively
181 To setup the branchpoint:
189 $EDITOR VERSION # bump the version number
197 add the new Mesa version X.Y.
207 These are the instructions for making a new Mesa release.
212 Ensure the latest code is available - both in your local main and the
218 Most of the testing should already be done during the
222 - the produced binaries work
261 Create release notes for the new release
264 The release notes are completely generated by the
266 bumping the version. You'll need to come back to this file once the
269 Increment the version contained in the file ``VERSION`` at Mesa's top-level,
270 then commit this change and **push the branch** (if you forget to do
273 Use the release.sh script from xorg `util-modular <https://cgit.freedesktop.org/xorg/util/modular/>`__
276 Start the release process.
282 Pay close attention to the prompts as you might be required to enter
283 your GPG and SSH passphrase(s) to sign and upload the files,
286 Ensure that you do sign the tarballs, that your key is mentioned in the
291 Add the sha256sums to the release notes
294 Edit ``docs/relnotes/X.Y.Z.rst`` to add the ``sha256sum`` as available in the
297 Back on mesa main, add the new release notes into the tree
300 Something like the following steps will do the trick:
307 Then run the
313 , where X.Y.Z is the version you just made. This will update
322 Announce the release
325 Use the generated template during the releasing process.
328 series, if that is the case.
333 Parse through the bug reports as listed in the docs/relnotes/X.Y.Z.rst
334 document. If there's outstanding action, close the bug referencing the
335 commit ID which addresses the bug and mention the Mesa version that has
336 the fix.
338 .. note: the above is not applicable to all the reports, so use common sense.