From 49b9186252a9e2cf57809ad04e75c801cbcb3622 Mon Sep 17 00:00:00 2001 From: Tanya Lattner Date: Wed, 19 Aug 2009 23:07:37 +0000 Subject: [PATCH] Update the release process some more. Lots of good details now. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79488 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/HowToReleaseLLVM.html | 170 ++++++++++++++++++++++++++----------- 1 file changed, 119 insertions(+), 51 deletions(-) diff --git a/docs/HowToReleaseLLVM.html b/docs/HowToReleaseLLVM.html index 0fd5903a10a..a5763000e68 100644 --- a/docs/HowToReleaseLLVM.html +++ b/docs/HowToReleaseLLVM.html @@ -93,8 +93,8 @@ pre-release testing.
  • Release final tasks
      • -
    1. Tag the LLVM Release Branch
    2. Update Documentation
      3. +
    3. Tag the LLVM Release Branch
    4. Update the LLVM Demo Page
    5. Update the LLVM Website
    6. Announce the Release
      7. @@ -129,7 +129,7 @@ release process to begin. Specifically, it involves creating the release branch,

      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/ + 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. @@ -175,9 +175,10 @@ 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. + for both. This must be done for both llvm and the + test-suite.

      -

      FIXME: Add a note about clang.

      +

      FIXME: Add a note about clang.

      In addition, the version number of all the Bugzilla components must be updated for the next release.

      @@ -187,9 +188,9 @@ svn co https://llvm.org/svn/llvm-project/cfe/branches/release_XX
      Build the LLVM Source Distributions

      - 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: + 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:

      @@ -211,16 +212,18 @@ tar -czvf - clang-X.X.source | gzip > clang-X.X.source.tar.gz Building the Release
      -Info about this. Criteria for a successful build. +The build of llvm, llvm-gcc, and clang must be free +of errors and warnings in both debug and release modes. If both debug and +release builds are clean, then the release passes build qualification.
      Build LLVM

      - 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 and release (optimized) versions of LLVM on all supported + platforms. Direction to build llvm are + here.

      @@ -235,7 +238,9 @@ Info about this. Criteria for a successful build.
      1. Build the LLVM GCC front-end by following the directions in the README.LLVM - file. Be sure to build with LLVM_VERSION_INFO=X.X, where X is the major and + file. The frontend must be compiled with c, c++, objc (mac only), + objc++ (mac only) and fortran support. + Be sure to build with LLVM_VERSION_INFO=X.X, where X is the major and minor release numbers.
        2. @@ -248,7 +253,8 @@ Info about this. Criteria for a successful build.
      -
      Build Clang Binary Distribution
      +
      Build Clang +Binary Distribution

      Creating the Clang binary distribution (release/optimized) requires @@ -257,11 +263,15 @@ Info about this. Criteria for a successful build.

      1. - Instructions how to build it. + Build clang according to the directions + here.
        2. + +
      2. Build both a debug and release version of clang, but the binary + will be a release build.
      3. - Instructions on how to package + Package clang (details to follow).
      @@ -272,8 +282,24 @@ Info about this. Criteria for a successful build. Details

      - Specify what is used to build llvm, llvm-gcc, clang on each target. + The table below specifies which compilers are used for each arch/os combination + when qualifying the build of llvm, llvm-gcc, clang. +

      + +

      + + + + + + + + + + +
      ArchitectureOScompiler
      x86-32Mac OS 10.5gcc 4.0.1
      x86-32Linuxgcc 4.2.X, gcc 4.3.X
      x86-32FreeBSDgcc ?
      x86-32mingwgcc ?
      x86-64Mac OS 10.5gcc 4.0.1
      x86-64Linuxgcc 4.2.X, gcc 4.3.X
      x86-64FreeBSDgcc?

      +
      @@ -282,7 +308,10 @@ Details Building the Release
      -How to qualify the release. + A release is qualified when it has no regressions from the previous + release (or baseline). Regressions are related to correctness only and not + performance at this time. Regressions are new failures in the set of tests that + are used to qualify each product and do not include anything not in the list.
      @@ -290,29 +319,45 @@ How to qualify the release.
      Qualify LLVM

      - Details

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

      Qualify LLVM-GCC

      - Details.

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

      Qualify Clang
      -

      - Details.

      + Clang is qualified when front-end specific tests in the + llvm dejagnu test suite all pass, clang's own test suite passes + cleanly, and there are no regressions in the test-suite.

      Specific Target Qualification Details
      -

      - Details

      +

      + + + + + + + + +
      ArchitectureOSllvm-gcc baselineclang baseline + tests
      x86-32Mac OS 10.5last releasenonellvm dejagnu, clang tests, test-suite (including spec)
      x86-32Linuxlast releasenonellvm dejagnu, clang tests, test-suite (including spec)
      x86-32FreeBSDnonenonellvm dejagnu, clang tests, test-suite
      x86-32mingwlast releasenoneQT
      x86-64Mac OS 10.5last releasenonellvm dejagnu, clang tests, test-suite (including spec)
      x86-64Linuxlast releasenonellvm dejagnu, clang tests, test-suite (including spec)
      x86-64FreeBSDnonenonellvm dejagnu, clang tests, test-suite

      @@ -323,24 +368,28 @@ Qualification Details 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:

        -
      1. Download llvm-X.X, llvm-test-X.X, and the appropriate llvm-gcc4 binary. - Run "make check" and the full llvm-test suite (make TEST=nightly report).
      2. -
      3. Download llvm-X.X, llvm-test-X.X, and the llvm-gcc4 source. Compile - everything. Run "make check" and the full llvm-test suite (make TEST=nightly +
      4. Download llvm-X.X, llvm-test-X.X, and the appropriate llvm-gcc4 + and/or clang binary. Build LLVM. + Run "make check" and the full llvm-test suite (make TEST=nightly report).
        5. +
      5. Download llvm-X.X, llvm-test-X.X, and the llvm-gcc4 and/or clang source. + Compile everything. Run "make check" and the full llvm-test suite (make TEST=nightly report).

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

      @@ -348,7 +397,19 @@ Qualification Details

      - Details

      + Below are the rules regarding patching the release branch.

      +

      +

    7. Patches applied to the release branch are only applied by the release + manager.
      8. +
    8. During the first round of testing, patches that fix regressions or that + are small and relatively risk free (verified by the appropriate code owner) + are applied to the branch. Code owners are asked to be very conservative in + approving patches for the branch and we reserve the right to reject any patch + that does not fix a regression as previously defined.
      9. +
    9. During the remaining rounds of testing, only patches that fix regressions + may be applied.
      10. + +

      @@ -357,10 +418,27 @@ Qualification Details

      - Details

      + The final stages of the release process involving taging 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.

      + +
      Update Documentation
      +
      +

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

      +
      +
      Tag the Release Branch
      @@ -377,18 +455,7 @@ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XX \
      - -
      Update Documentation
      -
      -

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

      -
      +
      Update the LLVM Demo Page
      @@ -408,7 +475,8 @@ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XX \
      1. Check out the website module from CVS.
      2. Create a new subdirectory X.X in the releases directory.
        3. -
      3. Commit the llvm, test-suite, llvm-gcc source, +
      4. Commit the llvm, test-suite, llvm-gcc source, + clang source, clang binaries, and llvm-gcc binaries in this new directory.
      5. Copy and commit the llvm/docs and LICENSE.txt files into this new directory. The docs should be built with BUILD_FOR_WEBSITE=1.
        6. -- 2.34.1