- This document collects information about successfully releasing LLVM to the - public. It is the release manager's guide to ensuring that a high quality + 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.
- -- The following is the basic criteria for releasing LLVM: -
- -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 + development 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 results.
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, and - the test-suite. The branch name will be release_XX, - where XX is the major and minor release numbers. These branches can - be created without checking out anything from subversion. +
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.
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. + 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, and the LLVM Test Suite by - exporting the source from Subversion and archiving it. This can be done with - the following commands: + 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:
- 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. + Build both debug, release+asserts (optimized), and release versions of + LLVM on all supported platforms. Direction to build llvm are + here.
Creating the LLVM GCC binary distribution (release/optimized) requires @@ -197,128 +244,201 @@ tar -cvf - llvm-gcc4.2-X.X.source | gzip > llvm-gcc-4.2-X.X.source.tar.gz
- Using the newly built llvm-gcc and llvm, reconfigure llvm to locate llvm-gcc. - Run make check and ensure there are no unexpected failures. If there - are, resolve the failures or file a bug. If there is a fix commited to mainline, - merge back into the release branch, and restart testing by - re-building LLVM and llvm-gcc. If no - fix will be made, XFAIL the test and commit back to the release branch. + Creating the Clang binary distribution (debug/release/release) requires + performing the following steps for each supported platform:
+- Ensure that 'make check' passes on all platforms for all targets. The - test suite must complete with "0 unexpected failures" before sending out the - pre-releases for testing. + The table below specifies which compilers are used for each arch/os combination + when qualifying the build of llvm, llvm-gcc, clang. +
+ ++
| Architecture | OS | compiler |
|---|---|---|
| x86-32 | Mac OS 10.5 | gcc 4.0.1 |
| x86-32 | Linux | gcc 4.2.X, gcc 4.3.X |
| x86-32 | FreeBSD | gcc 4.2.X |
| x86-32 | mingw | gcc 3.4.5 |
| x86-64 | Mac OS 10.5 | gcc 4.0.1 |
| x86-64 | Linux | gcc 4.2.X, gcc 4.3.X |
| x86-64 | FreeBSD | gcc 4.2.X |
- Run the llvm-test suite and ensure there are no unacceptable - failures. Unacceptable failures are regression from the previous release - and (optionally) major performance regressions from the previous release. - If a regression is found a bug is filled, but the pre-releases may still go - out.
+ LLVM is qualified when it has a clean dejagnu test run without a frontend and + it has no regressions when using either llvm-gcc or clang + with the test-suite from the previous release. +- You can, optionally, create source and binary RPM packages for LLVM. These may - make it easier to get LLVM into a distribution. This can be done with the - following commands: -
+ LLVM-GCC is qualified when front-end specific tests in the + llvm dejagnu test suite all pass and there are no regressions in + the test-suite. +We do not use the gcc dejagnu test suite as release criteria.
+-make dist # Build the distribution source tarball -make dist-check # Check that the source tarball can build itself. -cp llvm-M.m.tar.gz /usr/src/redhat/SOURCES # Required by rpmbuild -make srpm # for source rpm -make rpm # for binary rpm -+ + +
- First, use make dist to simply build the distribution. Any failures - need to be corrected (on the branch). Once make dist can be - successful, do make dist-check. This target will do the same thing as - the 'dist' target but also test that distribution to make sure it can build - itself and runs make check as well. This ensures that needed files - are not missing and that the src tarball can be successfully unpacked, built, - installed, and cleaned. Once you have a reliable tarball, you need to copy it - to the /usr/src/redhat/SOURCES directory which is a requirement of - the rpmbuild tool. The last two make invocations just run rpmbuild to - build either a source (srpm) or binary (rpm) RPM package. -
+ + +| Architecture | OS | llvm-gcc baseline | clang baseline + | tests |
|---|---|---|---|---|
| x86-32 | Linux | last release | last release | llvm dejagnu, clang tests, test-suite (including spec) |
| x86-32 | FreeBSD | none | last release | llvm dejagnu, clang tests, test-suite |
| x86-32 | mingw | last release | none | QT |
| x86-64 | Mac OS 10.X | last release | last release | llvm dejagnu, clang tests, test-suite (including spec) |
| x86-64 | Linux | last release | last release | llvm dejagnu, clang tests, test-suite (including spec) |
| x86-64 | FreeBSD | none | last release | llvm dejagnu, clang tests, test-suite |
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.
+ Attempt to verify that there are no regressions from the previous release. + The results are not used to qualify a release, but to spot other potential + problems. 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).
+During the first round of testing time, + all regressions must be fixed before the second pre-release is created.
-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.
+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. +
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 -+
+ Below are the rules regarding patching the release branch.
++
+ The final stages of the release process involving tagging the release branch, + updating documentation that refers to the release, and updating the demo + page.
+FIXME: Add a note if anything needs to be done to the clang website. + Eventually the websites will be merged hopefully.
Review the documentation and ensure that it is up to date. The Release Notes @@ -330,6 +450,24 @@ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XX \
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 ++
The website must be updated before the release announcement is sent out. Here is @@ -348,7 +486,8 @@ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XX \
Have Chris send out the release announcement when everything is finished.
- The first thing you need to understand is that there are multiple make targets - to support this feature. Here's an overview, we'll delve into the details - later. -
- -- Okay, that's the basic functionality. When making a release, we want to ensure - that the tree you build the distribution from passes - dist-check. Beyond fixing the usual bugs, there is generally one - impediment to making the release in this fashion: missing files. The - dist-check process guards against that possibility. It will either - fail and that failure will indicate what's missing, or it will succeed meaning - that it has proved that the tarballs can actually succeed in building LLVM - correctly and that it passes make check. -
-- This target builds the distribution directory which is the directory from - which the tarballs are generated. The distribution directory has the same - name as the release, e.g. LLVM-1.7). This target goes through the following - process: -
- -- To control the process of making the distribution directory correctly, each - Makefile can utilize two features: -
- -- You will see various messages if things go wrong: -
- -- This target does exactly what distdir target does, but also includes - assembling the tarballs. There are actually four related targets here: -
- -- This target checks the distribution. The basic idea is that it unpacks the - distribution tarball and ensures that it can build. It takes the following - actions: -
- -- If it can pass all that, the distribution will be deemed distribution worth y - and you will see: -
- -===== LLVM-1.7.tar.gz Ready For Distribution =====- -
- This means the tarball should then be tested on other platforms and have the - nightly test run against it. If those all pass, THEN it is ready for - distribution. -
- -- A note about disk space: using dist-check will easily triple the - amount of disk space your build tree is using. You might want to check - available space before you begin. -
-- In addition to doing a normal clean, this target will clean up the - files and directories created by the distribution targets. In particular the - distribution directory (LLVM-X.X), check directory - (_distcheckdir), and the various tarballs will be removed. You do - this after the release has shipped and you no longer need this stuff in your - build tree. -
-