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