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