This document collects information about successfully releasing LLVM (including subprojects llvm-gcc and Clang) to the public. It is the release manager's responsibility to ensure that a high quality build of LLVM is released.
LLVM is released on a time based schedule (currently every 6 months). We do not have dot releases because of the nature of LLVM incremental developement philosophy. The release schedule is roughly as follows:
Branch the Subversion HEAD using the following procedure:
Verify that the current Subversion HEAD is in decent shape by examining nightly tester or buildbot results.
Request all developers to refrain from committing. Offenders get commit rights taken away (temporarily).
Create the release branch for llvm, llvm-gcc4.2, clang, and the test-suite. The branch name will be release_XX,where XX is the major and minor release numbers. Clang will have a different release number than llvm/ llvm-gcc4 since its first release was years later (still deciding if this will be true or not). These branches can be created without checking out anything from subversion.
svn copy https://llvm.org/svn/llvm-project/llvm/trunk \ https://llvm.org/svn/llvm-project/llvm/branches/release_XX svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk \ https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XX svn copy https://llvm.org/svn/llvm-project/test-suite/trunk \ https://llvm.org/svn/llvm-project/test-suite/branches/release_XX svn copy https://llvm.org/svn/llvm-project/cfe/trunk \ https://llvm.org/svn/llvm-project/cfe/branches/release_XX
Advise developers they can work on Subversion HEAD again.
The Release Manager should switch to the release branch (as all changes to the release will now be done in the branch). The easiest way to do this is to grab another working copy using the following commands:
svn co https://llvm.org/svn/llvm-project/llvm/branches/release_XX svn co https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XX svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_XX svn co https://llvm.org/svn/llvm-project/cfe/branches/release_XX
After creating the LLVM release branch, update the release branches' autoconf/configure.ac version from X.Xsvn to just X.X. Update it on mainline as well to be the next version (X.X+1svn). Regenerated the configure script for both. This must be done for both llvm and the test-suite.
FIXME: Add a note about clang.
In addition, the version number of all the Bugzilla components must be updated for the next release.
Create source distributions for LLVM, LLVM GCC, Clang, and the LLVM Test Suite by exporting the source from Subversion and archiving it. This can be done with the following commands:
svn export https://llvm.org/svn/llvm-project/llvm/branches/release_XX llvm-X.X svn export https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XX llvm-gcc4.2-X.X.source svn export https://llvm.org/svn/llvm-project/test-suite/branches/release_XX llvm-test-X.X svn export https://llvm.org/svn/llvm-project/cfe/branches/release_XX clang-X.X tar -czvf - llvm-X.X | gzip > llvm-X.X.tar.gz tar -czvf - llvm-test-X.X | gzip > llvm-test-X.X.tar.gz tar -czvf - llvm-gcc4.2-X.X.source | gzip > llvm-gcc-4.2-X.X.source.tar.gz tar -czvf - clang-X.X.source | gzip > clang-X.X.source.tar.gz
Build both debug and release (optimized) versions of LLVM on all platforms. Ensure the build is warning and error free on each platform. Note that when building the LLVM GCC Binary, use a release build of LLVM.
Creating the LLVM GCC binary distribution (release/optimized) requires performing the following steps for each supported platform:
Creating the Clang binary distribution (release/optimized) requires performing the following steps for each supported platform:
Specify what is used to build llvm, llvm-gcc, clang on each target.
Details
Details.
Details.
Details
Once all testing has been completed and appropriate bugs filed, the pre-release tar balls may be put on the website and the LLVM community is notified. Ask that all LLVM developers test the release in 2 ways:
Ask LLVM developers to submit the report and make check results to the list. Verify that there are no regressions from the previous release. For unsupported targets, verify that make check at least is clean.
The first round of pre-release testing will be the longest. During this time, all regressions must be fixed before the second pre-release is created (repeat steps 4-8).
If this is the second round of testing, this is only to ensure the 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 step.
Details
Details
Tag the release branch using the following procedure:
svn copy https://llvm.org/svn/llvm-project/llvm/branches/release_XX \ https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_XX svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XX \ https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_XX svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XX \ https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_XX
Review the documentation and ensure that it is up to date. The Release Notes must be updated to reflect bug fixes, new known issues, and changes in the list of supported platforms. The Getting Started Guide should be updated to reflect the new release version number tag avaiable from Subversion and changes in basic system requirements. Merge both changes from mainline into the release branch.
The LLVM demo page must be updated to use the new release. This consists of using the llvm-gcc binary and building LLVM. Update the website demo page configuration to use the new release.
The website must be updated before the release announcement is sent out. Here is what to do:
Have Chris send out the release announcement when everything is finished.