.. contents::
:local:
-
-.. sectionauthor:: Tanya Lattner <tonic@nondot.org>,
- Reid Spencer <rspencer@x10sys.com>,
- John Criswell <criswell@cs.uiuc.edu> and
- Bill Wendling <wendling@apple.com>
+ :depth: 1
Introduction
============
is the Release Manager's responsibility to ensure that a high quality build of
LLVM is released.
+If you're looking for the document on how to test the release candidates and
+create the binary packages, please refer to the :doc:`ReleaseProcess` instead.
+
.. _timeline:
Release Timeline
================
-LLVM is released on a time based schedule --- roughly every 6 months. We do
-not normally have dot releases because of the nature of LLVM's incremental
-development philosophy. That said, the only thing preventing dot releases for
-critical bug fixes from happening is a lack of resources --- testers,
-machines, time, etc. And, because of the high quality we desire for LLVM
-releases, we cannot allow for a truncated form of release qualification.
+LLVM is released on a time based schedule --- with major releases roughly
+every 6 months. In between major releases there may be dot releases.
+The release manager will determine if and when to make a dot release based
+on feedback from the community. Typically, dot releases should be made if
+there are large number of bug-fixes in the stable branch or a critical bug
+has been discovered that affects a large number of users.
+
+Unless otherwise stated, dot releases will follow the same procedure as
+major releases.
The release process is roughly as follows:
* Finally, release!
-.. _process:
+The release process will be accelerated for dot releases. If the first round
+of testing finds no critical bugs and no regressions since the last major release,
+then additional rounds of testing will not be required.
Release Process
===============
-#. :ref:`Release Administrative Tasks <release-admin>`
-
- #. :ref:`Create Release Branch <branch>`
-
- #. :ref:`Update Version Numbers <verchanges>`
-
-#. :ref:`Building the Release <release-build>`
-
- #. :ref:`Build the LLVM Source Distribution <dist>`
-
- #. :ref:`Build LLVM <build>`
-
- #. :ref:`Build the Clang Binary Distribution <clangbin>`
-
- #. :ref:`Target Specific Build Details <target-build>`
-
-#. :ref:`Release Qualification Criteria <release-qualify>`
-
- #. :ref:`Qualify LLVM <llvm-qualify>`
-
- #. :ref:`Qualify Clang <clang-qualify>`
-
- #. :ref:`Specific Target Qualification Details <target>`
-
-#. :ref:`Community Testing <commTest>`
-
-#. :ref:`Release Patch Rules <release-patch>`
-
-#. :ref:`Release final tasks <release-final>`
-
- #. :ref:`Update Documentation <updocs>`
-
- #. :ref:`Tag the LLVM Final Release <tag>`
-
- #. :ref:`Update the LLVM Demo Page <updemo>`
-
- #. :ref:`Update the LLVM Website <webupdates>`
-
- #. :ref:`Announce the Release <announce>`
-
-.. _release-admin:
+.. contents::
+ :local:
Release Administrative Tasks
----------------------------
* Creating the release branch,
* Setting version numbers, and
-
-* Tagging release candidates for the release team to begin testing.
-.. _branch:
+* Tagging release candidates for the release team to begin testing.
Create Release Branch
^^^^^^^^^^^^^^^^^^^^^
``dragonegg`` from the last known good revision. The branch's name is
``release_XY``, where ``X`` is the major and ``Y`` the minor release
numbers. The branches should be created using the following commands:
-
+
::
-
+
$ svn copy https://llvm.org/svn/llvm-project/llvm/trunk \
https://llvm.org/svn/llvm-project/llvm/branches/release_XY
-
+
$ svn copy https://llvm.org/svn/llvm-project/cfe/trunk \
https://llvm.org/svn/llvm-project/cfe/branches/release_XY
-
+
$ svn copy https://llvm.org/svn/llvm-project/dragonegg/trunk \
https://llvm.org/svn/llvm-project/dragonegg/branches/release_XY
-
+
$ svn copy https://llvm.org/svn/llvm-project/test-suite/trunk \
https://llvm.org/svn/llvm-project/test-suite/branches/release_XY
tree again.
#. The Release Manager should switch to the release branch, because all changes
- to the release will now be done in the branch. The easiest way to do this is
+ to the release will now be done in the branch. The easiest way to do this is
to grab a working copy using the following commands:
::
-
+
$ svn co https://llvm.org/svn/llvm-project/llvm/branches/release_XY llvm-X.Y
-
+
$ svn co https://llvm.org/svn/llvm-project/cfe/branches/release_XY clang-X.Y
-
+
$ svn co https://llvm.org/svn/llvm-project/dragonegg/branches/release_XY dragonegg-X.Y
-
- $ svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_XY test-suite-X.Y
-.. _verchanges:
+ $ svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_XY test-suite-X.Y
Update LLVM Version
^^^^^^^^^^^^^^^^^^^
In addition, the version numbers of all the Bugzilla components must be updated
for the next release.
-.. _dist:
-
-Build the LLVM Release Candidates
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Tagging the LLVM Release Candidates
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Create release candidates for ``llvm``, ``clang``, ``dragonegg``, and the LLVM
-``test-suite`` by tagging the branch with the respective release candidate
-number. For instance, to create **Release Candidate 1** you would issue the
-following commands:
+Tag release candidates using the tag.sh script in utils/release.
::
- $ svn mkdir https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_XY
- $ svn copy https://llvm.org/svn/llvm-project/llvm/branches/release_XY \
- https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_XY/rc1
-
- $ svn mkdir https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_XY
- $ svn copy https://llvm.org/svn/llvm-project/cfe/branches/release_XY \
- https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_XY/rc1
-
- $ svn mkdir https://llvm.org/svn/llvm-project/dragonegg/tags/RELEASE_XY
- $ svn copy https://llvm.org/svn/llvm-project/dragonegg/branches/release_XY \
- https://llvm.org/svn/llvm-project/dragonegg/tags/RELEASE_XY/rc1
-
- $ svn mkdir https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_XY
- $ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XY \
- https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_XY/rc1
-
-Similarly, **Release Candidate 2** would be named ``RC2`` and so on. This keeps
-a permanent copy of the release candidate around for people to export and build
-as they wish. The final released sources will be tagged in the ``RELEASE_XY``
-directory as ``Final`` (c.f. :ref:`Tag the LLVM Final Release <tag>`).
+ $ ./tag.sh -release X.Y.Z -rc $RC
The Release Manager may supply pre-packaged source tarballs for users. This can
-be done with the following commands:
+be done with the export.sh script in utils/release.
::
- $ svn export https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_XY/rc1 llvm-X.Yrc1
- $ svn export https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_XY/rc1 clang-X.Yrc1
- $ svn export https://llvm.org/svn/llvm-project/dragonegg/tags/RELEASE_XY/rc1 dragonegg-X.Yrc1
- $ svn export https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_XY/rc1 llvm-test-X.Yrc1
-
- $ tar -cvf - llvm-X.Yrc1 | gzip > llvm-X.Yrc1.src.tar.gz
- $ tar -cvf - clang-X.Yrc1 | gzip > clang-X.Yrc1.src.tar.gz
- $ tar -cvf - dragonegg-X.Yrc1 | gzip > dragonegg-X.Yrc1.src.tar.gz
- $ tar -cvf - llvm-test-X.Yrc1 | gzip > llvm-test-X.Yrc1.src.tar.gz
+ $ ./export.sh -release X.Y.Z -rc $RC
-.. _release-build:
+This will generate source tarballs for each LLVM project being validated, which
+can be uploaded to the website for further testing.
Building the Release
--------------------
| Release | ``ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1`` |
+-----------------+---------------------------------------------+
-
-.. _build:
-
Build LLVM
^^^^^^^^^^
Build ``Debug``, ``Release+Asserts``, and ``Release`` versions
of ``llvm`` on all supported platforms. Directions to build ``llvm``
-are :ref:`here <getting_started>`.
-
-.. _clangbin:
+are :doc:`here <GettingStarted>`.
Build Clang Binary Distribution
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#. Package ``clang`` (details to follow).
-.. _target-build:
-
Target Specific Build Details
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+--------------+---------------+----------------------+
| x86-64 | FreeBSD | gcc 4.2.X |
+--------------+---------------+----------------------+
-
-.. _release-qualify:
+| ARMv7 | Linux | gcc 4.6.X, gcc 4.7.X |
++--------------+---------------+----------------------+
Release Qualification Criteria
------------------------------
criteria, but these are the criteria which we found to be most important and
which must be satisfied before a release can go out.**
-.. _llvm-qualify:
-
Qualify LLVM
^^^^^^^^^^^^
no regressions when using either ``clang`` or ``dragonegg`` with the
``test-suite`` from the previous release.
-.. _clang-qualify:
-
Qualify Clang
^^^^^^^^^^^^^
-``Clang`` is qualified when front-end specific tests in the ``llvm`` dejagnu
+``Clang`` is qualified when front-end specific tests in the ``llvm`` regression
test suite all pass, clang's own test suite passes cleanly, and there are no
regressions in the ``test-suite``.
-.. _target:
-
Specific Target Qualification Details
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+--------------+-------------+----------------+-----------------------------+
| Architecture | OS | clang baseline | tests |
+==============+=============+================+=============================+
-| x86-32 | Linux | last release | llvm dejagnu, |
-| | | | clang tests, |
+| x86-32 | Linux | last release | llvm regression tests, |
+| | | | clang regression tests, |
| | | | test-suite (including spec) |
+--------------+-------------+----------------+-----------------------------+
-| x86-32 | FreeBSD | last release | llvm dejagnu, |
-| | | | clang tests, |
+| x86-32 | FreeBSD | last release | llvm regression tests, |
+| | | | clang regression tests, |
| | | | test-suite |
+--------------+-------------+----------------+-----------------------------+
| x86-32 | mingw | none | QT |
+--------------+-------------+----------------+-----------------------------+
-| x86-64 | Mac OS 10.X | last release | llvm dejagnu, |
-| | | | clang tests, |
+| x86-64 | Mac OS 10.X | last release | llvm regression tests, |
+| | | | clang regression tests, |
| | | | test-suite (including spec) |
+--------------+-------------+----------------+-----------------------------+
-| x86-64 | Linux | last release | llvm dejagnu, |
-| | | | clang tests, |
+| x86-64 | Linux | last release | llvm regression tests, |
+| | | | clang regression tests, |
| | | | test-suite (including spec) |
+--------------+-------------+----------------+-----------------------------+
-| x86-64 | FreeBSD | last release | llvm dejagnu, |
-| | | | clang tests, |
+| x86-64 | FreeBSD | last release | llvm regression tests, |
+| | | | clang regression tests, |
+| | | | test-suite |
++--------------+-------------+----------------+-----------------------------+
+| ARMv7A | Linux | last release | llvm regression tests, |
+| | | | clang regression tests, |
| | | | test-suite |
+--------------+-------------+----------------+-----------------------------+
-
-.. _commTest:
Community Testing
-----------------
The results are not used to qualify a release, but to spot other potential
problems. For unsupported targets, verify that ``make check`` is at least
clean.
-
+
During the first round of testing, all regressions must be fixed before the
second release candidate is tagged.
-
+
If this is the second round of testing, the testing is only to ensure that bug
fixes previously merged in have not created new major problems. *This is not
the time to solve additional and unrelated bugs!* If no patches are merged in,
the release is determined to be ready and the release manager may move onto the
next stage.
-.. _release-patch:
-
Release Patch Rules
-------------------
#. During the remaining rounds of testing, only patches that fix critical
regressions may be applied.
-.. _release-final:
+#. For dot releases all patches must mantain both API and ABI compatibility with
+ the previous major release. Only bugfixes will be accepted.
Release Final Tasks
-------------------
branch, updating documentation that refers to the release, and updating the
demo page.
-.. _updocs:
-
Update Documentation
^^^^^^^^^^^^^^^^^^^^
Tag the LLVM Final Release
^^^^^^^^^^^^^^^^^^^^^^^^^^
-Tag the final release sources using the following procedure:
+Tag the final release sources using the tag.sh script in utils/release.
::
- $ svn copy https://llvm.org/svn/llvm-project/llvm/branches/release_XY \
- https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_XY/Final
-
- $ svn copy https://llvm.org/svn/llvm-project/cfe/branches/release_XY \
- https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_XY/Final
-
- $ svn copy https://llvm.org/svn/llvm-project/dragonegg/branches/release_XY \
- https://llvm.org/svn/llvm-project/dragonegg/tags/RELEASE_XY/Final
-
- $ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XY \
- https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_XY/Final
-
-.. _updemo:
+ $ ./tag.sh -release X.Y.Z -final
Update the LLVM Demo Page
-------------------------
The LLVM demo page must be updated to use the new release. This consists of
using the new ``clang`` binary and building LLVM.
-.. _webupdates:
-
Update the LLVM Website
^^^^^^^^^^^^^^^^^^^^^^^
new release and release announcement. Make sure this all gets committed back
into Subversion.
-.. _announce:
-
Announce the Release
^^^^^^^^^^^^^^^^^^^^
projects / oota-llvm.git / blobdiff