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 <div class="doc_title">How To Release LLVM To The Public</div>
  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 <div class="doc_section"><a name="introduction">Introduction</a></div>
  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 <div class="doc_section"><a name="process">Release Timeline</a></div>
  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 <div class="doc_section"><a name="process">Release Process</a></div>
  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 <div class="doc_subsection"><a name="release-admin">Release Administrative Tasks</a></div>
 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 <div class="doc_subsubsection"><a name="branch">Create Release Branch</a></div>
 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 <div class="doc_subsubsection"><a name="verchanges">Update LLVM Version</a></div>
 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 <div class="doc_subsubsection"><a name="dist">Build the LLVM Release Candidates</a></div>
 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 <div class="doc_subsection"><a name="release-build">Building the Release</a></div>
 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 <div class="doc_subsubsection"><a name="build">Build LLVM</a></div>
 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 <div class="doc_subsubsection"><a name="llvmgccbin">Build the LLVM GCC Binary Distribution</a></div>
 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 <div class="doc_subsubsection"><a name="clangbin">Build Clang Binary Distribution</a></div>
 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 <div class="doc_subsubsection"><a name="target-build">Target Specific Build Details</a></div>
 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 <div class="doc_subsection"><a name="release-qualify">
 376 Building the Release</a></div>
 377
 378 <div class="doc_text">
 379
 380 <p>A release is qualified when it has no regressions from the previous release
 381    (or baseline). Regressions are related to correctness first and performance
 382    second. (We may tolerate some minor performance regressions if they are
 383    deemed necessary for the general quality of the compiler.)</p>
 384
 385 <p><b>Regressions are new failures in the set of tests that are used to qualify
 386    each product and only include things on the list. Every release will have
 387    some bugs in it. It is the reality of developing a complex piece of
 388    software. We need a very concrete and definitive release criteria that
 389    ensures we have monotonically improving quality on some metric. The metric we
 390    use is described below. This doesn't mean that we don't care about other
 391    criteria, but these are the criteria which we found to be most important and
 392    which must be satisfied before a release can go out</b></p>
 393
 394 </div>
 395
 396 <!-- ======================================================================= -->
 397 <div class="doc_subsubsection"><a name="llvm-qualify">Qualify LLVM</a></div>
 398
 399 <div class="doc_text">
 400
 401 <p>LLVM is qualified when it has a clean test run without a front-end. And it
 402    has no regressions when using either <tt>llvm-gcc</tt> or <tt>clang</tt> with
 403    the <tt>test-suite</tt> from the previous release.</p>
 404
 405 </div>
 406
 407 <!-- ======================================================================= -->
 408 <div class="doc_subsubsection"><a name="llvmgcc-qualify">Qualify LLVM-GCC</a></div>
 409
 410 <div class="doc_text">
 411
 412 <p><tt>LLVM-GCC</tt> is qualified when front-end specific tests in the
 413    <tt>llvm</tt> regression test suite all pass and there are no regressions in
 414    the <tt>test-suite</tt>.</p>
 415
 416 <p>We do not use the GCC DejaGNU test suite as release criteria.</p>
 417
 418 </div>
 419
 420 <!-- ======================================================================= -->
 421 <div class="doc_subsubsection"><a name="clang-qualify">Qualify Clang</a></div>
 422
 423 <div class="doc_text">
 424
 425 <p><tt>Clang</tt> is qualified when front-end specific tests in the
 426    <tt>llvm</tt> dejagnu test suite all pass, clang's own test suite passes
 427    cleanly, and there are no regressions in the <tt>test-suite</tt>.</p>
 428
 429 </div>
 430
 431 <!-- ======================================================================= -->
 432 <div class="doc_subsubsection"><a name="targets">Specific Target
 433 Qualification Details</a></div>
 434
 435 <div class="doc_text">
 436
 437 <table>
 438   <tr><th>Architecture</th><th>OS</th><th>llvm-gcc baseline</th><th>clang baseline</th><th>tests</th></tr>
 439   <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>
 440   <tr><td>x86-32</td><td>FreeBSD</td><td>none</td><td>last release</td><td>llvm dejagnu, clang tests, test-suite</td></tr>
 441   <tr><td>x86-32</td><td>mingw</td><td>last release</td><td>none</td><td>QT</td></tr>
 442   <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>
 443   <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>
 444   <tr><td>x86-64</td><td>FreeBSD</td><td>none</td><td>last release</td><td>llvm dejagnu, clang tests, test-suite</td></tr>
 445 </table>
 446
 447 </div>
 448
 449 <!-- ======================================================================= -->
 450 <div class="doc_subsection"><a name="commTest">Community Testing</a></div>
 451 <div class="doc_text">
 452
 453 <p>Once all testing has been completed and appropriate bugs filed, the release
 454    candidate tarballs are put on the website and the LLVM community is
 455    notified. Ask that all LLVM developers test the release in 2 ways:</p>
 456
 457 <ol>
 458   <li>Download <tt>llvm-<i>X.Y</i></tt>, <tt>llvm-test-<i>X.Y</i></tt>, and the
 459       appropriate <tt>llvm-gcc</tt> and/or <tt>clang</tt> binary. Build
 460       LLVM. Run <tt>make check</tt> and the full LLVM test suite (<tt>make
 461       TEST=nightly report</tt>).</li>
 462
 463   <li>Download <tt>llvm-<i>X.Y</i></tt>, <tt>llvm-test-<i>X.Y</i></tt>, and the
 464       <tt>llvm-gcc</tt> and/or <tt>clang</tt> source. Compile everything. Run
 465       <tt>make check</tt> and the full LLVM test suite (<tt>make TEST=nightly
 466       report</tt>).</li>
 467 </ol>
 468
 469 <p>Ask LLVM developers to submit the test suite report and <tt>make check</tt>
 470    results to the list. Verify that there are no regressions from the previous
 471    release. The results are not used to qualify a release, but to spot other
 472    potential problems. For unsupported targets, verify that <tt>make check</tt>
 473    is at least clean.</p>
 474
 475 <p>During the first round of testing, all regressions must be fixed before the
 476    second release candidate is tagged.</p>
 477
 478 <p>If this is the second round of testing, the testing is only to ensure that
 479    bug fixes previously merged in have not created new major problems. <i>This
 480    is not the time to solve additional and unrelated bugs!</i> If no patches are
 481    merged in, the release is determined to be ready and the release manager may
 482    move onto the next stage.</p>
 483
 484 </div>
 485
 486 <!-- ======================================================================= -->
 487 <div class="doc_subsection"><a name="release-patch">Release Patch Rules</a></div>
 488
 489 <div class="doc_text">
 490
 491 <p>Below are the rules regarding patching the release branch:</p>
 492
 493 <ol>
 494   <li><p>Patches applied to the release branch may only be applied by the
 495       release manager.</p></li>
 496
 497   <li><p>During the first round of testing, patches that fix regressions or that
 498       are small and relatively risk free (verified by the appropriate code
 499       owner) are applied to the branch. Code owners are asked to be very
 500       conservative in approving patches for the branch. We reserve the right to
 501       reject any patch that does not fix a regression as previously
 502       defined.</p></li>
 503
 504   <li><p>During the remaining rounds of testing, only patches that fix critical
 505       regressions may be applied.</p></li>
 506 </ol>
 507
 508 </div>
 509
 510 <!-- ======================================================================= -->
 511 <div class="doc_subsection"><a name="release-final">Release Final Tasks
 512 </a></div>
 513
 514 <div class="doc_text">
 515
 516 <p>The final stages of the release process involves tagging the "final" release
 517    branch, updating documentation that refers to the release, and updating the
 518    demo page.</p>
 519
 520 </div>
 521
 522
 523 <!-- ======================================================================= -->
 524 <div class="doc_subsubsection"><a name="updocs">Update Documentation</a></div>
 525
 526 <div class="doc_text">
 527
 528 <p>Review the documentation and ensure that it is up to date. The "Release
 529    Notes" must be updated to reflect new features, bug fixes, new known issues,
 530    and changes in the list of supported platforms. The "Getting Started Guide"
 531    should be updated to reflect the new release version number tag avaiable from
 532    Subversion and changes in basic system requirements. Merge both changes from
 533    mainline into the release branch.</p>
 534
 535 </div>
 536
 537 <!-- ======================================================================= -->
 538 <div class="doc_subsubsection"><a name="tag">Tag the LLVM Final Release</a></div>
 539
 540 <div class="doc_text">
 541
 542 <p>Tag the final release sources using the following procedure:</p>
 543
 544 <div class="doc_code">
 545 <pre>
 546 $ svn copy https://llvm.org/svn/llvm-project/llvm/branches/release_XY \
 547            https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_<i>XY</i>/Final
 548
 549 $ svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XY \
 550            https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_<i>XY</i>/Final
 551
 552 $ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XY \
 553            https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_<i>XY</i>/Final
 554
 555 $ svn copy https://llvm.org/svn/llvm-project/cfe/branches/release_XY \
 556            https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_<i>XY</i>/Final
 557 </pre>
 558 </div>
 559
 560 </div>
 561
 562 <!-- ======================================================================= -->
 563 <div class="doc_subsection"><a name="updemo">Update the LLVM Demo Page</a></div>
 564
 565 <div class="doc_text">
 566
 567 <p>The LLVM demo page must be updated to use the new release. This consists of
 568    using the new <tt>llvm-gcc</tt> binary and building LLVM.</p>
 569
 570 </div>
 571
 572 <!-- ======================================================================= -->
 573 <div class="doc_subsubsection"><a name="webupdates">Update the LLVM Website</a></div>
 574
 575 <div class="doc_text">
 576
 577 <p>The website must be updated before the release announcement is sent out. Here
 578    is what to do:</p>
 579
 580 <ol>
 581   <li>Check out the <tt>www</tt> module from Subversion.</li>
 582
 583   <li>Create a new subdirectory <tt>X.Y</tt> in the releases directory.</li>
 584
 585   <li>Commit the <tt>llvm</tt>, <tt>test-suite</tt>, <tt>llvm-gcc</tt> source,
 586       <tt>clang source</tt>, <tt>clang binaries</tt>, and <tt>llvm-gcc</tt>
 587       binaries in this new directory.</li>
 588
 589   <li>Copy and commit the <tt>llvm/docs</tt> and <tt>LICENSE.txt</tt> files
 590       into this new directory. The docs should be built with
 591       <tt>BUILD_FOR_WEBSITE=1</tt>.</li>
 592
 593   <li>Commit the <tt>index.html</tt> to the <tt>release/X.Y</tt> directory to
 594       redirect (use from previous release.</li>
 595
 596   <li>Update the <tt>releases/download.html</tt> file with the new release.</li>
 597
 598   <li>Update the <tt>releases/index.html</tt> with the new release and link to
 599       release documentation.</li>
 600
 601   <li>Finally, update the main page (<tt>index.html</tt> and sidebar) to point
 602       to the new release and release announcement. Make sure this all gets
 603       committed back into Subversion.</li>
 604 </ol>
 605
 606 </div>
 607
 608 <!-- ======================================================================= -->
 609 <div class="doc_subsubsection"><a name="announce">Announce the Release</a></div>
 610
 611 <div class="doc_text">
 612
 613 <p>Have Chris send out the release announcement when everything is finished.</p>
 614
 615 </div>
 616
 617 <!-- *********************************************************************** -->
 618 <hr>
 619 <address>
 620   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
 621   src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
 622   <a href="http://validator.w3.org/check/referer"><img
 623   src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
 624   <a href="http://llvm.org/">The LLVM Compiler Infrastructure</a>
 625   <br>
 626   Last modified: $Date$
 627 </address>
 628 </body>
 629 </html>