|  | .. _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 |