docs/HowToReleaseLLVM.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   2                       "http://www.w3.org/TR/html4/strict.dtd">
   3 <html>
   4 <head>
   5   <title>How To Release LLVM To The Public</title>
   6   <link rel="stylesheet" href="llvm.css" type="text/css">
   7 </head>
   8 <body>
   9
  10 <h1>How To Release LLVM To The Public</h1>
  11 <ol>
  12   <li><a href="#introduction">Introduction</a></li>
  13   <li><a href="#criteria">Qualification Criteria</a></li>
  14   <li><a href="#introduction">Release Timeline</a></li>
  15   <li><a href="#process">Release Process</a></li>
  16 </ol>
  17 <div class="doc_author">
  18   <p>Written by <a href="mailto:tonic@nondot.org">Tanya Lattner</a>,
  19   <a href="mailto:rspencer@x10sys.com">Reid Spencer</a>,
  20   <a href="mailto:criswell@cs.uiuc.edu">John Criswell</a>, &amp;
  21   <a href="mailto:wendling@apple.com">Bill Wendling</a>
  22   </p>
  23 </div>
  24
  25 <!-- *********************************************************************** -->
  26 <h2><a name="introduction">Introduction</a></h2>
  27 <!-- *********************************************************************** -->
  28
  29 <div class="doc_text">
  30
  31 <p>This document contains information about successfully releasing LLVM &mdash;
  32    including subprojects: e.g., <tt>llvm-gcc</tt> and <tt>clang</tt> &mdash; to
  33    the public. It is the Release Manager's responsibility to ensure that a high
  34    quality build of LLVM is released.</p>
  35
  36 </div>
  37
  38 <!-- *********************************************************************** -->
  39 <h2><a name="process">Release Timeline</a></h2>
  40 <!-- *********************************************************************** -->
  41 <div class="doc_text">
  42
  43 <p>LLVM is released on a time based schedule &mdash; roughly every 6 months. We
  44    do not normally have dot releases because of the nature of LLVM's incremental
  45    development philosophy. That said, the only thing preventing dot releases for
  46    critical bug fixes from happening is a lack of resources &mdash; testers,
  47    machines, time, etc. And, because of the high quality we desire for LLVM
  48    releases, we cannot allow for a truncated form of release qualification.</p>
  49
  50 <p>The release process is roughly as follows:</p>
  51
  52 <ul>
  53   <li><p>Set code freeze and branch creation date for 6 months after last code
  54       freeze date. Announce release schedule to the LLVM community and update
  55       the website.</p></li>
  56
  57   <li><p>Create release branch and begin release process.</p></li>
  58
  59   <li><p>Send out release candidate sources for first round of testing. Testing
  60       lasts 7-10 days. During the first round of testing, any regressions found
  61       should be fixed. Patches are merged from mainline into the release
  62       branch. Also, all features need to be completed during this time. Any
  63       features not completed at the end of the first round of testing will be
  64       removed or disabled for the release.</p></li>
  65
  66   <li><p>Generate and send out the second release candidate sources. Only
  67       <em>critial</em> bugs found during this testing phase will be fixed. Any
  68       bugs introduced by merged patches will be fixed. If so a third round of
  69       testing is needed.</p></li>
  70
  71   <li><p>The release notes are updated.</p></li>
  72
  73   <li><p>Finally, release!</p></li>
  74 </ul>
  75
  76 </div>
  77
  78 <!-- *********************************************************************** -->
  79 <h2><a name="process">Release Process</a></h2>
  80 <!-- *********************************************************************** -->
  81
  82 <div class="doc_text">
  83
  84 <ol>
  85   <li><a href="#release-admin">Release Administrative Tasks</a>
  86   <ol>
  87     <li><a href="#branch">Create Release Branch</a></li>
  88     <li><a href="#verchanges">Update Version Numbers</a></li>
  89   </ol>
  90   </li>
  91   <li><a href="#release-build">Building the Release</a>
  92   <ol>
  93     <li><a href="#dist">Build the LLVM Source Distributions</a></li>
  94     <li><a href="#build">Build LLVM</a></li>
  95     <li><a href="#llvmgccbin">Build the LLVM-GCC Binary Distribution</a></li>
  96     <li><a href="#clangbin">Build the Clang Binary Distribution</a></li>
  97     <li><a href="#target-build">Target Specific Build Details</a></li>
  98   </ol>
  99   </li>
 100   <li><a href="#release-qualify">Release Qualification Criteria</a>
 101   <ol>
 102     <li><a href="#llvm-qualify">Qualify LLVM</a></li>
 103     <li><a href="#llvmgcc-qualify">Qualify LLVM-GCC</a></li>
 104     <li><a href="#clang-qualify">Qualify Clang</a></li>
 105     <li><a href="#targets">Specific Target Qualification Details</a></li>
 106   </ol>
 107   </li>
 108
 109   <li><a href="#commTest">Community Testing</a></li>
 110   <li><a href="#release-patch">Release Patch Rules</a></li>
 111   <li><a href="#release-final">Release final tasks</a>
 112   <ol>
 113     <li><a href="#updocs">Update Documentation</a></li>
 114     <li><a href="#tag">Tag the LLVM Final Release</a></li>
 115     <li><a href="#updemo">Update the LLVM Demo Page</a></li>
 116     <li><a href="#webupdates">Update the LLVM Website</a></li>
 117     <li><a href="#announce">Announce the Release</a></li>
 118   </ol>
 119   </li>
 120 </ol>
 121
 122 </div>
 123
 124 <!-- ======================================================================= -->
 125 <h3><a name="release-admin">Release Administrative Tasks</a></h3>
 126
 127 <div class="doc_text">
 128
 129 <p>This section describes a few administrative tasks that need to be done for
 130    the release process to begin. Specifically, it involves:</p>
 131
 132 <ul>
 133   <li>Creating the release branch,</li>
 134   <li>Setting version numbers, and</li>
 135   <li>Tagging release candidates for the release team to begin testing</li>
 136 </ul>
 137
 138 </div>
 139
 140 <!-- ======================================================================= -->
 141 <h4><a name="branch">Create Release Branch</a></h4>
 142
 143 <div class="doc_text">
 144
 145 <p>Branch the Subversion trunk using the following procedure:</p>
 146
 147 <ol>
 148   <li><p>Remind developers that the release branching is imminent and to refrain
 149       from committing patches that might break the build. E.g., new features,
 150       large patches for works in progress, an overhaul of the type system, an
 151       exciting new TableGen feature, etc.</p></li>
 152
 153   <li><p>Verify that the current Subversion trunk is in decent shape by
 154       examining nightly tester and buildbot results.</p></li>
 155
 156   <li><p>Create the release branch for <tt>llvm</tt>, <tt>llvm-gcc-4.2</tt>,
 157       <tt>clang</tt>, and the <tt>test-suite</tt> from the last known good
 158       revision. The branch's name is <tt>release_XY</tt>, where <tt>X</tt> is
 159       the major and <tt>Y</tt> the minor release numbers. The branches should be
 160       created using the following commands:</p>
 161
 162 <div class="doc_code">
 163 <pre>
 164 $ svn copy https://llvm.org/svn/llvm-project/llvm/trunk \
 165            https://llvm.org/svn/llvm-project/llvm/branches/release_<i>XY</i>
 166
 167 $ svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk \
 168            https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_<i>XY</i>
 169
 170 $ svn copy https://llvm.org/svn/llvm-project/test-suite/trunk \
 171            https://llvm.org/svn/llvm-project/test-suite/branches/release_<i>XY</i>
 172
 173 $ svn copy https://llvm.org/svn/llvm-project/cfe/trunk \
 174            https://llvm.org/svn/llvm-project/cfe/branches/release_<i>XY</i>
 175 </pre>
 176 </div></li>
 177
 178   <li><p>Advise developers that they may now check their patches into the
 179       Subversion tree again.</p></li>
 180
 181   <li><p>The Release Manager should switch to the release branch, because all
 182       changes to the release will now be done in the branch. The easiest way to
 183       do this is to grab a working copy using the following commands:</p>
 184
 185 <div class="doc_code">
 186 <pre>
 187 $ svn co https://llvm.org/svn/llvm-project/llvm/branches/release_<i>XY</i> llvm-<i>X.Y</i>
 188
 189 $ svn co https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_<i>XY</i> llvm-gcc-4.2-<i>X.Y</i>
 190
 191 $ svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_<i>XY</i> test-suite-<i>X.Y</i>
 192
 193 $ svn co https://llvm.org/svn/llvm-project/cfe/branches/release_<i>XY</i> clang-<i>X.Y</i>
 194 </pre>
 195 </div></li>
 196 </ol>
 197
 198 </div>
 199
 200 <!-- ======================================================================= -->
 201 <h4><a name="verchanges">Update LLVM Version</a></h4>
 202
 203 <div class="doc_text">
 204
 205 <p>After creating the LLVM release branch, update the release branches'
 206    <tt>autoconf</tt> and <tt>configure.ac</tt> versions from '<tt>X.Ysvn</tt>'
 207    to '<tt>X.Y</tt>'. Update it on mainline as well to be the next version
 208    ('<tt>X.Y+1svn</tt>'). Regenerate the configure scripts for both
 209    <tt>llvm</tt> and the <tt>test-suite</tt>.</p>
 210
 211 <p>In addition, the version numbers of all the Bugzilla components must be
 212    updated for the next release.</p>
 213
 214 </div>
 215
 216 <!-- ======================================================================= -->
 217 <h4><a name="dist">Build the LLVM Release Candidates</a></h4>
 218
 219 <div class="doc_text">
 220
 221 <p>Create release candidates for <tt>llvm</tt>, <tt>llvm-gcc</tt>,
 222    <tt>clang</tt>, and the LLVM <tt>test-suite</tt> by tagging the branch with
 223    the respective release candidate number. For instance, to create <b>Release
 224    Candidate 1</b> you would issue the following commands:</p>
 225
 226 <div class="doc_code">
 227 <pre>
 228 $ svn mkdir https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_<i>XY</i>
 229 $ svn copy https://llvm.org/svn/llvm-project/llvm/branches/release_<i>XY</i> \
 230            https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_<i>XY</i>/rc1
 231
 232 $ svn mkdir https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_<i>XY</i>
 233 $ svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_<i>XY</i> \
 234            https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_<i>XY</i>/rc1
 235
 236 $ svn mkdir https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_<i>XY</i>
 237 $ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_<i>XY</i> \
 238            https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_<i>XY</i>/rc1
 239
 240 $ svn mkdir https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_<i>XY</i>
 241 $ svn copy https://llvm.org/svn/llvm-project/cfe/branches/release_<i>XY</i> \
 242            https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_<i>XY</i>/rc1
 243 </pre>
 244 </div>
 245
 246 <p>Similarly, <b>Release Candidate 2</b> would be named <tt>RC2</tt> and so
 247    on. This keeps a permanent copy of the release candidate around for people to
 248    export and build as they wish. The final released sources will be tagged in
 249    the <tt>RELEASE_<i>XY</i></tt> directory as <tt>Final</tt>
 250    (c.f. <a href="#tag">Tag the LLVM Final Release</a>).</p>
 251
 252 <p>The Release Manager may supply pre-packaged source tarballs for users. This
 253    can be done with the following commands:</p>
 254
 255 <div class="doc_code">
 256 <pre>
 257 $ svn export https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_<i>XY</i>/rc1 llvm-<i>X.Y</i>rc1
 258 $ svn export https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_<i>XY</i>/rc1 llvm-gcc4.2-<i>X.Y</i>rc1
 259 $ svn export https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_<i>XY</i>/rc1 llvm-test-<i>X.Y</i>rc1
 260 $ svn export https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_<i>XY</i>/rc1 clang-<i>X.Y</i>rc1
 261
 262 $ tar -cvf - llvm-<i>X.Y</i>rc1        | gzip &gt; llvm-<i>X.Y</i>rc1.src.tar.gz
 263 $ tar -cvf - llvm-test-<i>X.Y</i>rc1   | gzip &gt; llvm-test-<i>X.Y</i>rc1.src.tar.gz
 264 $ tar -cvf - llvm-gcc4.2-<i>X.Y</i>rc1 | gzip &gt; llvm-gcc-4.2-<i>X.Y</i>rc1.src.tar.gz
 265 $ tar -cvf - clang-<i>X.Y</i>rc1       | gzip &gt; clang-<i>X.Y</i>rc1.src.tar.gz
 266 </pre>
 267 </div>
 268
 269 </div>
 270
 271 <!-- ======================================================================= -->
 272 <h3><a name="release-build">Building the Release</a></h3>
 273
 274 <div class="doc_text">
 275
 276 <p>The builds of <tt>llvm</tt>, <tt>llvm-gcc</tt>, and <tt>clang</tt>
 277    <em>must</em> be free of errors and warnings in Debug, Release+Asserts, and
 278    Release builds. If all builds are clean, then the release passes Build
 279    Qualification.</p>
 280
 281 <p>The <tt>make</tt> options for building the different modes:</p>
 282
 283 <table>
 284   <tr><th>Mode</th><th>Options</th></tr>
 285   <tr align="left"><td>Debug</td><td><tt>ENABLE_OPTIMIZED=0</tt></td></tr>
 286   <tr align="left"><td>Release+Asserts</td><td><tt>ENABLE_OPTIMIZED=1</tt></td></tr>
 287   <tr align="left"><td>Release</td><td><tt>ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1</tt></td></tr>
 288 </table>
 289
 290 </div>
 291
 292 <!-- ======================================================================= -->
 293 <h4><a name="build">Build LLVM</a></h4>
 294
 295 <div class="doc_text">
 296
 297 <p>Build <tt>Debug</tt>, <tt>Release+Asserts</tt>, and <tt>Release</tt> versions
 298    of <tt>llvm</tt> on all supported platforms. Directions to build
 299    <tt>llvm</tt> are
 300    <a href="GettingStarted.html#quickstart">here</a>.</p>
 301
 302 </div>
 303
 304 <!-- ======================================================================= -->
 305 <h4><a name="llvmgccbin">Build the LLVM GCC Binary Distribution</a></h4>
 306
 307 <div class="doc_text">
 308
 309 <p>Creating the <tt>llvm-gcc</tt> binary distribution (Release/Optimized)
 310    requires performing the following steps for each supported platform:</p>
 311
 312 <ol>
 313   <li><p>Build the <tt>llvm-gcc</tt> front-end by following the directions in
 314       the <tt>README.LLVM</tt> file. The front-end must be compiled with C, C++,
 315       Objective-C (Mac only), Objective-C++ (Mac only), and Fortran
 316       support.</p></li>
 317
 318   <li><p>Boostrapping must be enabled.</p></li>
 319
 320   <li><p>Be sure to build with <tt>LLVM_VERSION_INFO=X.Y</tt>, where <tt>X</tt>
 321       is the major and <tt>Y</tt> is the minor release numbers.</p></li>
 322
 323   <li><p>Copy the installation directory to a directory named for the specific
 324       target. For example on Red Hat Enterprise Linux, the directory would be
 325       named <tt>llvm-gcc4.2-2.6-x86-linux-RHEL4</tt>. Archive and compress the
 326       new directory.</p></li>
 327 </ol>
 328
 329 </div>
 330
 331 <!-- ======================================================================= -->
 332 <h4><a name="clangbin">Build Clang Binary Distribution</a></h4>
 333
 334 <div class="doc_text">
 335
 336 <p>Creating the <tt>clang</tt> binary distribution
 337    (Debug/Release+Asserts/Release) requires performing the following steps for
 338    each supported platform:</p>
 339
 340 <ol>
 341   <li>Build clang according to the directions
 342       <a href="http://clang.llvm.org/get_started.html">here</a>.</li>
 343
 344   <li>Build both a debug and release version of clang. The binary will be the
 345       release build.</lI>
 346
 347   <li>Package <tt>clang</tt> (details to follow).</li>
 348 </ol>
 349
 350 </div>
 351
 352 <!-- ======================================================================= -->
 353 <h4><a name="target-build">Target Specific Build Details</a></h4>
 354
 355 <div class="doc_text">
 356
 357 <p>The table below specifies which compilers are used for each Arch/OS
 358    combination when qualifying the build of <tt>llvm</tt>, <tt>llvm-gcc</tt>,
 359    and <tt>clang</tt>.</p>
 360
 361 <table>
 362   <tr><th>Architecture</th><th>OS</th><th>compiler</th></tr>
 363   <tr><td>x86-32</td><td>Mac OS 10.5</td><td>gcc 4.0.1</td></tr>
 364   <tr><td>x86-32</td><td>Linux</td><td>gcc 4.2.X, gcc 4.3.X</td></tr>
 365   <tr><td>x86-32</td><td>FreeBSD</td><td>gcc 4.2.X</td></tr>
 366   <tr><td>x86-32</td><td>mingw</td><td>gcc 3.4.5</td></tr>
 367   <tr><td>x86-64</td><td>Mac OS 10.5</td><td>gcc 4.0.1</td></tr>
 368   <tr><td>x86-64</td><td>Linux</td><td>gcc 4.2.X, gcc 4.3.X</td></tr>
 369   <tr><td>x86-64</td><td>FreeBSD</td><td>gcc 4.2.X</td></tr>
 370 </table>
 371
 372 </div>
 373
 374 <!-- ======================================================================= -->
 375 <h3><a name="release-qualify">Building the Release</a></h3>
 376
 377 <div class="doc_text">
 378
 379 <p>A release is qualified when it has no regressions from the previous release
 380    (or baseline). Regressions are related to correctness first and performance
 381    second. (We may tolerate some minor performance regressions if they are
 382    deemed necessary for the general quality of the compiler.)</p>
 383
 384 <p><b>Regressions are new failures in the set of tests that are used to qualify
 385    each product and only include things on the list. Every release will have
 386    some bugs in it. It is the reality of developing a complex piece of
 387    software. We need a very concrete and definitive release criteria that
 388    ensures we have monotonically improving quality on some metric. The metric we
 389    use is described below. This doesn't mean that we don't care about other
 390    criteria, but these are the criteria which we found to be most important and
 391    which must be satisfied before a release can go out</b></p>
 392
 393 </div>
 394
 395 <!-- ======================================================================= -->
 396 <h4><a name="llvm-qualify">Qualify LLVM</a></h4>
 397
 398 <div class="doc_text">
 399
 400 <p>LLVM is qualified when it has a clean test run without a front-end. And it
 401    has no regressions when using either <tt>llvm-gcc</tt> or <tt>clang</tt> with
 402    the <tt>test-suite</tt> from the previous release.</p>
 403
 404 </div>
 405
 406 <!-- ======================================================================= -->
 407 <h4><a name="llvmgcc-qualify">Qualify LLVM-GCC</a></h4>
 408
 409 <div class="doc_text">
 410
 411 <p><tt>LLVM-GCC</tt> is qualified when front-end specific tests in the
 412    <tt>llvm</tt> regression test suite all pass and there are no regressions in
 413    the <tt>test-suite</tt>.</p>
 414
 415 <p>We do not use the GCC DejaGNU test suite as release criteria.</p>
 416
 417 </div>
 418
 419 <!-- ======================================================================= -->
 420 <h4><a name="clang-qualify">Qualify Clang</a></h4>
 421
 422 <div class="doc_text">
 423
 424 <p><tt>Clang</tt> is qualified when front-end specific tests in the
 425    <tt>llvm</tt> dejagnu test suite all pass, clang's own test suite passes
 426    cleanly, and there are no regressions in the <tt>test-suite</tt>.</p>
 427
 428 </div>
 429
 430 <!-- ======================================================================= -->
 431 <h4><a name="targets">Specific Target Qualification Details</a></h4>
 432
 433 <div class="doc_text">
 434
 435 <table>
 436   <tr><th>Architecture</th><th>OS</th><th>llvm-gcc baseline</th><th>clang baseline</th><th>tests</th></tr>
 437   <tr><td>x86-32</td><td>Linux</td><td>last release</td><td>last release</td><td>llvm dejagnu, clang tests, test-suite (including spec)</td></tr>
 438   <tr><td>x86-32</td><td>FreeBSD</td><td>none</td><td>last release</td><td>llvm dejagnu, clang tests, test-suite</td></tr>
 439   <tr><td>x86-32</td><td>mingw</td><td>last release</td><td>none</td><td>QT</td></tr>
 440   <tr><td>x86-64</td><td>Mac OS 10.X</td><td>last release</td><td>last release</td><td>llvm dejagnu, clang tests, test-suite (including spec)</td></tr>
 441   <tr><td>x86-64</td><td>Linux</td><td>last release</td><td>last release</td><td>llvm dejagnu, clang tests, test-suite (including spec)</td></tr>
 442   <tr><td>x86-64</td><td>FreeBSD</td><td>none</td><td>last release</td><td>llvm dejagnu, clang tests, test-suite</td></tr>
 443 </table>
 444
 445 </div>
 446
 447 <!-- ======================================================================= -->
 448 <h3><a name="commTest">Community Testing</a></h3>
 449 <div class="doc_text">
 450
 451 <p>Once all testing has been completed and appropriate bugs filed, the release
 452    candidate tarballs are put on the website and the LLVM community is
 453    notified. Ask that all LLVM developers test the release in 2 ways:</p>
 454
 455 <ol>
 456   <li>Download <tt>llvm-<i>X.Y</i></tt>, <tt>llvm-test-<i>X.Y</i></tt>, and the
 457       appropriate <tt>llvm-gcc</tt> and/or <tt>clang</tt> binary. Build
 458       LLVM. Run <tt>make check</tt> and the full LLVM test suite (<tt>make
 459       TEST=nightly report</tt>).</li>
 460
 461   <li>Download <tt>llvm-<i>X.Y</i></tt>, <tt>llvm-test-<i>X.Y</i></tt>, and the
 462       <tt>llvm-gcc</tt> and/or <tt>clang</tt> source. Compile everything. Run
 463       <tt>make check</tt> and the full LLVM test suite (<tt>make TEST=nightly
 464       report</tt>).</li>
 465 </ol>
 466
 467 <p>Ask LLVM developers to submit the test suite report and <tt>make check</tt>
 468    results to the list. Verify that there are no regressions from the previous
 469    release. The results are not used to qualify a release, but to spot other
 470    potential problems. For unsupported targets, verify that <tt>make check</tt>
 471    is at least clean.</p>
 472
 473 <p>During the first round of testing, all regressions must be fixed before the
 474    second release candidate is tagged.</p>
 475
 476 <p>If this is the second round of testing, the testing is only to ensure that
 477    bug fixes previously merged in have not created new major problems. <i>This
 478    is not the time to solve additional and unrelated bugs!</i> If no patches are
 479    merged in, the release is determined to be ready and the release manager may
 480    move onto the next stage.</p>
 481
 482 </div>
 483
 484 <!-- ======================================================================= -->
 485 <h3><a name="release-patch">Release Patch Rules</a></h3>
 486
 487 <div class="doc_text">
 488
 489 <p>Below are the rules regarding patching the release branch:</p>
 490
 491 <ol>
 492   <li><p>Patches applied to the release branch may only be applied by the
 493       release manager.</p></li>
 494
 495   <li><p>During the first round of testing, patches that fix regressions or that
 496       are small and relatively risk free (verified by the appropriate code
 497       owner) are applied to the branch. Code owners are asked to be very
 498       conservative in approving patches for the branch. We reserve the right to
 499       reject any patch that does not fix a regression as previously
 500       defined.</p></li>
 501
 502   <li><p>During the remaining rounds of testing, only patches that fix critical
 503       regressions may be applied.</p></li>
 504 </ol>
 505
 506 </div>
 507
 508 <!-- ======================================================================= -->
 509 <h3><a name="release-final">Release Final Tasks</a></h3>
 510
 511 <div class="doc_text">
 512
 513 <p>The final stages of the release process involves tagging the "final" release
 514    branch, updating documentation that refers to the release, and updating the
 515    demo page.</p>
 516
 517 </div>
 518
 519
 520 <!-- ======================================================================= -->
 521 <h4><a name="updocs">Update Documentation</a></h4>
 522
 523 <div class="doc_text">
 524
 525 <p>Review the documentation and ensure that it is up to date. The "Release
 526    Notes" must be updated to reflect new features, bug fixes, new known issues,
 527    and changes in the list of supported platforms. The "Getting Started Guide"
 528    should be updated to reflect the new release version number tag avaiable from
 529    Subversion and changes in basic system requirements. Merge both changes from
 530    mainline into the release branch.</p>
 531
 532 </div>
 533
 534 <!-- ======================================================================= -->
 535 <h4><a name="tag">Tag the LLVM Final Release</a></h4>
 536
 537 <div class="doc_text">
 538
 539 <p>Tag the final release sources using the following procedure:</p>
 540
 541 <div class="doc_code">
 542 <pre>
 543 $ svn copy https://llvm.org/svn/llvm-project/llvm/branches/release_XY \
 544            https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_<i>XY</i>/Final
 545
 546 $ svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XY \
 547            https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_<i>XY</i>/Final
 548
 549 $ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XY \
 550            https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_<i>XY</i>/Final
 551
 552 $ svn copy https://llvm.org/svn/llvm-project/cfe/branches/release_XY \
 553            https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_<i>XY</i>/Final
 554 </pre>
 555 </div>
 556
 557 </div>
 558
 559 <!-- ======================================================================= -->
 560 <h3><a name="updemo">Update the LLVM Demo Page</a></h3>
 561
 562 <div class="doc_text">
 563
 564 <p>The LLVM demo page must be updated to use the new release. This consists of
 565    using the new <tt>llvm-gcc</tt> binary and building LLVM.</p>
 566
 567 </div>
 568
 569 <!-- ======================================================================= -->
 570 <h4><a name="webupdates">Update the LLVM Website</a></h4>
 571
 572 <div class="doc_text">
 573
 574 <p>The website must be updated before the release announcement is sent out. Here
 575    is what to do:</p>
 576
 577 <ol>
 578   <li>Check out the <tt>www</tt> module from Subversion.</li>
 579
 580   <li>Create a new subdirectory <tt>X.Y</tt> in the releases directory.</li>
 581
 582   <li>Commit the <tt>llvm</tt>, <tt>test-suite</tt>, <tt>llvm-gcc</tt> source,
 583       <tt>clang source</tt>, <tt>clang binaries</tt>, and <tt>llvm-gcc</tt>
 584       binaries in this new directory.</li>
 585
 586   <li>Copy and commit the <tt>llvm/docs</tt> and <tt>LICENSE.txt</tt> files
 587       into this new directory. The docs should be built with
 588       <tt>BUILD_FOR_WEBSITE=1</tt>.</li>
 589
 590   <li>Commit the <tt>index.html</tt> to the <tt>release/X.Y</tt> directory to
 591       redirect (use from previous release.</li>
 592
 593   <li>Update the <tt>releases/download.html</tt> file with the new release.</li>
 594
 595   <li>Update the <tt>releases/index.html</tt> with the new release and link to
 596       release documentation.</li>
 597
 598   <li>Finally, update the main page (<tt>index.html</tt> and sidebar) to point
 599       to the new release and release announcement. Make sure this all gets
 600       committed back into Subversion.</li>
 601 </ol>
 602
 603 </div>
 604
 605 <!-- ======================================================================= -->
 606 <h4><a name="announce">Announce the Release</a></h4>
 607
 608 <div class="doc_text">
 609
 610 <p>Have Chris send out the release announcement when everything is finished.</p>
 611
 612 </div>
 613
 614 <!-- *********************************************************************** -->
 615 <hr>
 616 <address>
 617   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
 618   src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
 619   <a href="http://validator.w3.org/check/referer"><img
 620   src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
 621   <a href="http://llvm.org/">The LLVM Compiler Infrastructure</a>
 622   <br>
 623   Last modified: $Date$
 624 </address>
 625 </body>
 626 </html>