mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2024-12-15 12:09:51 +00:00
b88db47bd2
This way, we don't need to remove the contents of the ReleaseNotes file after the branch. This should make it much easier and natural to cherry-pick changes onto the release branch. Typically, we need two patches for those. First, we need the code changes against `main`, and then we need a patch that updates the release notes on the just-created branch. By versioning the release notes, it becomes easy to author a change against `main` that targets a just-branched LLVM release by simply adding it to the release notes for the right version. This has been a pain point in previous releases. Differential Revision: https://reviews.llvm.org/D155024
79 lines
2.9 KiB
ReStructuredText
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/index.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
|