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>, & 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 — 32 including subprojects: e.g., <tt>llvm-gcc</tt> and <tt>clang</tt> — 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 — 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 — 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 > llvm-<i>X.Y</i>rc1.src.tar.gz 259$ tar -cvf - llvm-test-<i>X.Y</i>rc1 | gzip > llvm-test-<i>X.Y</i>rc1.src.tar.gz 260$ tar -cvf - llvm-gcc4.2-<i>X.Y</i>rc1 | gzip > llvm-gcc-4.2-<i>X.Y</i>rc1.src.tar.gz 261$ tar -cvf - clang-<i>X.Y</i>rc1 | gzip > 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> 626