Files
RedBear-OS/local/recipes/dev/libclc/source/libcxx/docs/ReleaseProcedure.rst
T
vasilito cb424d7448 build: static patch-sanity linter (shift-left the malformed-patch class)
verify-patch-sanity.py validates every active recipe .patch has internally-
consistent hunk line counts — catching the 'malformed patch at line N' failure
at commit/CI/preflight time instead of hours into a cook. This cycle hit that
class three times (qtwaylandscanner, sddm, xwayland), each only discovered when
cookbook tried to apply the patch.

Running it across the repo found 29 latent malformed patches (validated against
GNU patch: e.g. relibc/P3-sysv-ipc reproduces 'malformed patch at line 22').
They were harmless only because they sit in vendored recipes (baked, not re-
applied) — but would fail on any version-bump re-derivation. --fix recounts the
hunk headers (body untouched) and repaired all 29.

Wired into build-preflight.sh (Phase 1.0D) and redbear-ci.yml, with a unit test
(test-patch-sanity.sh). Skips archived/legacy trees and unvalidatable formats
(empty placeholders, bare-@@ git hunks).
2026-08-01 05:13:02 +03:00

79 lines
2.9 KiB
ReStructuredText

.. _ReleaseProcedure:
=================
Release procedure
=================
The LLVM project creates a new release twice a year following a fixed
`schedule <https://llvm.org/docs/HowToReleaseLLVM.html#annual-release-schedule>`__.
This page describes the libc++ procedure for that release.
Prepare the release
===================
This is done by the libc++ developers.
It should be finished before the Release managers start branching the new
release:
* Make sure ``libcxx/docs/ReleaseNotes/<VERSION>.rst`` is up to date. Typically
this file is updated when contributing patches. Still there might be some
information added regarding the general improvements of larger projects.
* Make sure the deprecated features on this page are up to date. Typically a
new deprecated feature should be added to the release notes and this page.
However this should be verified so removals won't get forgotten.
* Make sure the latest Unicode version is used. The C++ Standard
`refers to the Unicode Standard <https://wg21.link/intro.refs#1.10>`__
``The Unicode Consortium. The Unicode Standard. Available from: https://www.unicode.org/versions/latest/``
Typically the Unicode Consortium has one release per year. The libc++
format library uses the Unicode Standard. Libc++ should be updated to the
latest Unicode version. Updating means using the latest data files and, if
needed, adapting the code to changes in the Unicode Standard.
* Make sure all libc++ supported compilers in the CI are updated to their
latest release.
Branching
=========
This is done by the LLVM Release managers.
After branching for an LLVM release:
1. Update ``_LIBCPP_VERSION`` in ``libcxx/include/__config``
2. Update the version number in ``libcxx/docs/conf.py``
3. Update ``_LIBCPPABI_VERSION`` in ``libcxxabi/include/cxxabi.h``
4. Update ``_LIBUNWIND_VERSION`` in ``libunwind/include/__libunwind_config.h``
5. Create a release notes file for the next release from the template
6. Point to the new release notes file from ``libcxx/docs/ReleaseNotes.rst``
Post branching
==============
This is done by the libc++ developers.
After branching it takes a couple of days before the new LLVM ToT version is
available on `<https://apt.llvm.org>`_. Once it is available the pre-commit CI
can start using the new ToT version. In order to make sure patches can be
backported to the release branch the oldest compiler is not removed yet.
The section ``Upcoming Deprecations and Removals`` is cleared by the release
managers. Copy back the items that were in this section.
The items that need changing are marked with ``LLVM POST-BRANCH``.
Post release
============
This is done by the libc++ developers.
Support for the ToT - 3 version is removed:
- Search for ``LLVM RELEASE`` and address their comments
- Search for test that have ``UNSUPPORTED`` or ``XFAIL`` for the no longer supported version
- Search for ``TODO(LLVM-<ToT>)`` and address their comments