From: Bill Wendling Date: Mon, 28 Feb 2011 01:10:44 +0000 (+0000) Subject: Update the documentation on "How to Release LLVM". It lays out a new way of X-Git-Url: http://plrg.eecs.uci.edu/git/?p=oota-llvm.git;a=commitdiff_plain;h=36d6c4d5f63ec2d1170dadf69b51f02c70b4efdb Update the documentation on "How to Release LLVM". It lays out a new way of tagging and branching for the release. I will update this more throughout the 2.9 release process. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126604 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/docs/HowToReleaseLLVM.html b/docs/HowToReleaseLLVM.html index 933b158793b..1392a1d914b 100644 --- a/docs/HowToReleaseLLVM.html +++ b/docs/HowToReleaseLLVM.html @@ -17,7 +17,8 @@

Written by Tanya Lattner, Reid Spencer, - John Criswell + John Criswell, & + Bill Wendling

@@ -26,486 +27,588 @@
-

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

+ +

This document contains information about successfully releasing LLVM — + including subprojects: e.g., 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.

+
Release Timeline
-

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

-
    -
  1. Set code freeze and branch creation date for 6 months after last code freeze -date. Announce release schedule to the LLVM community and update the website.
    2. -
  2. Create release branch and begin release process.
    3. -
  3. Send out pre-release for first round of testing. Testing will last 7-10 days. -During the first round of testing, regressions should be found and fixed. Patches -are merged from mainline to the release branch.
    4. -
  4. Generate and send out second pre-release. Bugs found during this time will -not be fixed unless absolutely critical. Bugs introduce by patches merged in -will be fixed and if so, a 3rd round of testing is needed.
    5. -
  5. The release notes should be updated during the first and second round of -pre-release testing.
    6. -
  6. Finally, release!
    7. -
-
+

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.

+ +

The release process is roughly as follows:

+ + + +
Release Process
+ +
    +
  1. Release Administrative Tasks
      2. -
    1. Release Administrative Tasks
      2. -
      1. Create Release Branch
      2. Update Version Numbers
        3. -
      -
    2. Building the Release
      3. -
        +
      +
    3. Building the Release
      4. +
      1. Build the LLVM Source Distributions
      2. Build LLVM
      3. Build the LLVM-GCC Binary Distribution
      4. Build the Clang Binary Distribution
      5. Target Specific Build Details
        6. -
      - -
    4. Release Qualification Criteria
      5. -
        +
      +
    5. Release Qualification Criteria
      6. +
      1. Qualify LLVM
      2. Qualify LLVM-GCC
      3. Qualify Clang
      4. Specific Target Qualification Details
        5. -
      - -
    6. Community Testing
      7. -
    7. Release Patch Rules
      8. - - -
    8. Release final tasks
      9. -
        +
      + +
    9. Community Testing
      10. +
    10. Release Patch Rules
      11. +
    11. Release final tasks
      12. + +
      1. Update Documentation
        2. -
      2. Tag the LLVM Release Branch
        3. +
      3. Tag the LLVM Final Release
      4. Update the LLVM Demo Page
      5. Update the LLVM Website
      6. Announce the Release
        7. -
      -
    +
+
-
-Release Administrative Tasks
+
Release Administrative Tasks
-This section describes a few administrative tasks that need to be done for the -release process to begin. Specifically, it involves creating the release branch, - resetting version numbers, and creating the release tarballs for the release - team to begin testing. + +

This section describes a few administrative tasks that need to be done for + the release process to begin. Specifically, it involves:

+ + +
Create Release Branch
+
-

Branch the Subversion HEAD using the following procedure:

-
    -
  1. -

    Verify that the current Subversion HEAD is in decent shape by examining - nightly tester or buildbot results.

    2. -
  2. -

    Request all developers to refrain from committing. Offenders get commit - rights taken away (temporarily).

    3. -
  3. -

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

    + +

    Branch the Subversion trunk using the following procedure:

    + +
      +

    1. Remind developers that the release branching is imminent and to refrain + from committing patches that might break the build. E.g., new features, + large patches for works in progress, an overhaul of the type system, an + exciting new TableGen feature, etc.

      2. + +

    2. Verify that the current Subversion trunk is in decent shape by + examining nightly tester and buildbot results.

      3. + +

    3. Create the release branch for llvm, llvm-gcc-4.2, + clang, and the test-suite 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_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
+$ 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/llvm-gcc-4.2/trunk \
+           https://llvm.org/svn/llvm-project/llvm-gcc-4.2/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
+
+$ svn copy https://llvm.org/svn/llvm-project/cfe/trunk \
+           https://llvm.org/svn/llvm-project/cfe/branches/release_XY
      -
      +
      4. -
    4. -

      Advise developers they can work on Subversion HEAD again.

      5. - -
    5. -

      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:

      +

    6. Advise developers that they may now check their patches into the + Subversion tree again.

      7. + +

    7. 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 grab a 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
+$ svn co https://llvm.org/svn/llvm-project/llvm/branches/release_XY llvm-X.Y
+
+$ svn co https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XY llvm-gcc-4.2-X.Y
+
+$ svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_XY test-suite-X.Y
+
+$ svn co https://llvm.org/svn/llvm-project/cfe/branches/release_XY clang-X.Y
      8. +
    -
Update LLVM Version
+
-

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

+ +

After creating the LLVM release branch, update the release branches' + autoconf and configure.ac versions from 'X.Ysvn' + to 'X.Y'. Update it on mainline as well to be the next version + ('X.Y+1svn'). Regenerate the configure scripts for both + llvm and the test-suite.

+ +

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

+
-
Build the LLVM Source Distributions
+
Build the LLVM Release Candidates
+
-

- 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 release candidates for llvm, llvm-gcc, + clang, 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:

-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 | gzip > clang-X.X.tar.gz
+$ 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/llvm-gcc-4.2/tags/RELEASE_XY
+$ svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XY \
+           https://llvm.org/svn/llvm-project/llvm-gcc-4.2/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
+
+$ 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
+ +

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. Tag the LLVM Final Release).

+ +

The Release Manager may supply pre-packaged source tarballs for users. This + can be done with the following commands:

+ +
+
+$ svn export https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_XY/RC1 llvm-X.Yrc1
+$ svn export https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_XY/RC1 llvm-gcc4.2-X.Yrc1
+$ svn export https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_XY/RC1 llvm-test-X.Yrc1
+$ svn export https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_XY/RC1 clang-X.Yrc1
+
+$ tar -czvf - llvm-X.Yrc1        | gzip > llvm-X.Yrc1.src.tar.gz
+$ tar -czvf - llvm-test-X.Yrc1   | gzip > llvm-test-X.Yrc1.src.tar.gz
+$ tar -czvf - llvm-gcc4.2-X.Yrc1 | gzip > llvm-gcc-4.2-X.Yrc1.src.tar.gz
+$ tar -czvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.gz
+
+
+
-
-Building the Release
+
Building the Release
-The build of llvm, llvm-gcc, and clang must be free -of errors and warnings in both debug, release+asserts, and release builds. -If all builds are clean, then the release passes build qualification. -
    -
  1. debug: ENABLE_OPTIMIZED=0
    2. -
  2. release+asserts: ENABLE_OPTIMIZED=1
    3. -
  3. release: ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1
    4. -
+

The builds of llvm, llvm-gcc, and clang + must be free of errors and warnings in Debug, Release+Asserts, and + Release builds. If all builds are clean, then the release passes Build + Qualification.

+ +

The make options for building the different modes:

+ + + + + + +
ModeOptions
DebugENABLE_OPTIMIZED=0
Release+AssertsENABLE_OPTIMIZED=1
ReleaseENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1
+
Build LLVM
+
-

- Build both debug, release+asserts (optimized), and release versions of - LLVM on all supported platforms. Direction to build llvm are - here. -

+ +

Build Debug, Release+Asserts, and Release versions + of llvm on all supported platforms. Directions to build + llvm are + here.

+
Build the LLVM GCC Binary Distribution
+
-

- Creating the LLVM GCC binary distribution (release/optimized) requires - performing the following steps for each supported platform: -

-
    -
  1. - Build the LLVM GCC front-end by following the directions in the README.LLVM - file. The frontend must be compiled with c, c++, objc (mac only), - objc++ (mac only) and fortran support.
    2. -
  2. Please boostrap as well.
    3. -
  3. Be sure to build with LLVM_VERSION_INFO=X.X, where X is the major and - minor release numbers. -
    4. - -
  4. - Copy the installation directory to a directory named for the specific target. - For example on Red Hat Enterprise Linux, the directory would be named - llvm-gcc4.2-2.6-x86-linux-RHEL4. Archive and compress the new directory. -
    5. -
+

Creating the llvm-gcc binary distribution (Release/Optimized) + requires performing the following steps for each supported platform:

+ +
    +

  1. Build the llvm-gcc front-end by following the directions in + the README.LLVM file. The front-end must be compiled with C, C++, + Objective-C (Mac only), Objective-C++ (Mac only), and Fortran + support.

    2. + +

  2. Boostrapping must be enabled.

    3. + +

  3. Be sure to build with LLVM_VERSION_INFO=X.Y, where X + is the major and Y is the minor release numbers.

    4. + +

  4. Copy the installation directory to a directory named for the specific + target. For example on Red Hat Enterprise Linux, the directory would be + named llvm-gcc4.2-2.6-x86-linux-RHEL4. Archive and compress the + new directory.

    5. +
+
-
Build Clang -Binary Distribution
+
Build Clang Binary Distribution
+
-

- Creating the Clang binary distribution (debug/release/release) requires - performing the following steps for each supported platform: -

-
    -
  1. - 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. - -
  3. - Package clang (details to follow). -
    4. -
-
+

Creating the clang binary distribution + (Debug/Release+Asserts/Release) requires performing the following steps for + each supported platform:

+ +
    +
  1. Build clang according to the directions + here.
    2. + +
  2. Build both a debug and release version of clang. The binary will be the + release build.
    3. + +
  3. Package clang (details to follow).
    4. +
+ -
Target Specific Build -Details
+
Target Specific Build Details
+
-

- The table below specifies which compilers are used for each arch/os combination - when qualifying the build of llvm, llvm-gcc, clang. -

- -

- + +

The table below specifies which compilers are used for each Arch/OS + combination when qualifying the build of llvm, llvm-gcc, + and clang.

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

+
-
Building 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 only include things on the list. - Ultimately, there is no end to the number of possible bugs in a release. We - need a very concrete and definitive release criteria that ensures we have - monotonically improving quality on some metric. The metric we use is - described below. This doesn't mean that we don't care about other things, - but this are things that must be satisfied before a release can go out -
+

A release is qualified when it has no regressions from the previous release + (or baseline). Regressions are related to correctness first and performance + second. (We may tolerate some minor performance regressions if they are + deemed necessary for the general quality of the compiler.)

+ +

Regressions are new failures in the set of tests that are used to qualify + each product and only include things on the list. Every release will have + some bugs in it. It is the reality of developing a complex piece of + software. We need a very concrete and definitive release criteria that + ensures we have monotonically improving quality on some metric. The metric we + use is described below. This doesn't mean that we don't care about other + criteria, but these are the criteria which we found to be most important and + which must be satisfied before a release can go out

+ +
Qualify LLVM
+
-

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

+ +

LLVM is qualified when it has a clean test run without a front-end. And it + has no regressions when using either llvm-gcc or clang with + the test-suite from the previous release.

+
Qualify LLVM-GCC
+
-

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

+ +

LLVM-GCC is qualified when front-end specific tests in the + llvm regression 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
+
- 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.

+ +

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

- + +
ArchitectureOSllvm-gcc baselineclang baseline - tests
+ -
ArchitectureOSllvm-gcc baselineclang baselinetests
x86-32Linuxlast releaselast releasellvm dejagnu, clang tests, test-suite (including spec)
x86-32FreeBSDnonelast releasellvm dejagnu, clang tests, test-suite
x86-32mingwlast releasenoneQT
x86-64Mac OS 10.Xlast releaselast releasellvm dejagnu, clang tests, test-suite (including spec)
x86-64Linuxlast releaselast releasellvm dejagnu, clang tests, test-suite (including spec)
x86-64FreeBSDnonelast releasellvm dejagnu, clang tests, test-suite

+ +
Community Testing
-

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

-
    -
  1. 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).
    2. -
  2. 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).
    3. -
-

Ask LLVM developers to submit the report and make check results to the list. - 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.

+ +

Once all testing has been completed and appropriate bugs filed, the release + candidate tarballs are 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.Y, llvm-test-X.Y, and the + appropriate llvm-gcc and/or clang binary. Build + LLVM. Run make check and the full LLVM test suite (make + TEST=nightly report).
    2. + +
  2. Download llvm-X.Y, llvm-test-X.Y, and the + llvm-gcc and/or clang source. Compile everything. Run + make check and the full LLVM test suite (make TEST=nightly + report).
    3. +
+ +

Ask LLVM developers to submit the test suite report and make check + results to the list. 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 + is at least clean.

-

During the first round of testing time, - all regressions must be fixed before the second pre-release is created.

+

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, 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, 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 Rules -
+
Release Patch Rules
+
-

- Below are the rules regarding patching the release branch.

-

-

  • Patches applied to the release branch are only applied by the release - manager.
    • -
  • 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.
    • -
  • During the remaining rounds of testing, only patches that fix regressions - may be applied.
    • - -

    -
    +

    Below are the rules regarding patching the release branch:

    + +
      +

    1. Patches applied to the release branch may only be applied by the + release manager.

      2. + +

    2. 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. We reserve the right to + reject any patch that does not fix a regression as previously + defined.

      3. + +

    3. During the remaining rounds of testing, only patches that fix critical + regressions may be applied.

      4. +
    + +
    Release Final Tasks
    +
    -

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

    + +

    The final stages of the release process involves tagging the "final" release + branch, updating documentation that refers to the release, and updating the + demo page.

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

    + +

    Review the documentation and ensure that it is up to date. The "Release + Notes" must be updated to reflect new features, 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
    +
    Tag the LLVM Final Release
    +
    -

    Tag the release branch using the following procedure:

    + +

    Tag the final release sources 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
+$ 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/llvm-gcc-4.2/branches/release_XY \
+           https://llvm.org/svn/llvm-project/llvm-gcc-4.2/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
+
+$ svn copy https://llvm.org/svn/llvm-project/cfe/branches/release_XY \
+           https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_XY/Final
    -
    - +
    Update the LLVM Demo Page
    +
    -

    - 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 LLVM demo page must be updated to use the new release. This consists of + using the new llvm-gcc binary and building LLVM.

    +
    Update the LLVM Website
    +
    -

    - The website must be updated before the release announcement is sent out. Here is - what to do:

    -
      -
    1. Check out the website module from CVS.
      2. -
    2. Create a new subdirectory X.X in the releases directory.
      3. -
    3. Commit the llvm, test-suite, llvm-gcc source, - clang source, clang binaries, - and llvm-gcc binaries in this new directory.
      4. -
    4. Copy and commit the llvm/docs and LICENSE.txt - files into this new directory. The docs should be built with BUILD_FOR_WEBSITE=1.
      5. -
    5. Commit the index.html to the release/X.X directory to redirect (use from previous - release.
      6. -
    6. Update the releases/download.html file with the new release.
      7. -
    7. Update the releases/index.html with the new release and link to - release documentation.
      8. -
    8. Finally, update the main page (index.html and sidebar) to - point to the new release and release announcement. Make sure this all gets - committed back into Subversion.
      9. -
    + +

    The website must be updated before the release announcement is sent out. Here + is what to do:

    + +
      +
    1. Check out the www module from Subversion.
      2. + +
    2. Create a new subdirectory X.Y in the releases directory.
      3. + +
    3. Commit the llvm, test-suite, llvm-gcc source, + clang source, clang binaries, and llvm-gcc + binaries in this new directory.
      4. + +
    4. Copy and commit the llvm/docs and LICENSE.txt files + into this new directory. The docs should be built with + BUILD_FOR_WEBSITE=1.
      5. + +
    5. Commit the index.html to the release/X.Y directory to + redirect (use from previous release.
      6. + +
    6. Update the releases/download.html file with the new release.
      7. + +
    7. Update the releases/index.html with the new release and link to + release documentation.
      8. + +
    8. Finally, update the main page (index.html and sidebar) to point + to the new release and release announcement. Make sure this all gets + committed back into Subversion.
      9. +
    +
    Announce the Release
    +
    -

    Have Chris send out the release announcement when everything is finished.

    + +

    Have Chris send out the release announcement when everything is finished.

    +