1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
2 "http://www.w3.org/TR/html4/strict.dtd">
5 <title>How To Release LLVM To The Public</title>
6 <link rel="stylesheet" href="llvm.css" type="text/css">
10 <div class="doc_title">How To Release LLVM To The Public</div>
12 <li><a href="#introduction">Introduction</a></li>
13 <li><a href="#introduction">Release Timeline</a></li>
14 <li><a href="#process">Release Process</a></li>
15 <li><a href="#dist_targets">Distribution Targets</a></li>
17 <div class="doc_author">
18 <p>Written by <a href="mailto:rspencer@x10sys.com">Reid Spencer</a>,
19 <a href="mailto:criswell@cs.uiuc.edu">John Criswell</a>,
20 <a href="mailto:tonic@nondot.org">Tanya Lattner</a></p>
23 <!-- *********************************************************************** -->
24 <div class="doc_section"><a name="introduction">Introduction</a></div>
25 <!-- *********************************************************************** -->
27 <div class="doc_text">
29 This document collects information about successfully releasing LLVM to the
30 public. It is the release manager's guide to ensuring that a high quality
31 build of LLVM is released.
35 The following is the basic criteria for releasing LLVM:
39 <li>Successful configure and build.</li>
40 <li>Clean 'make check'.</li>
41 <li>No regressions in the testsuite from the previous release. This may
42 include performance regressions for major benchmarks.</li>
46 <!-- *********************************************************************** -->
47 <div class="doc_section"><a name="process">Release Timeline</a></div>
48 <!-- *********************************************************************** -->
49 <div class="doc_text">
50 The release manager should attempt to have a release every 3-4 months because LLVM
51 does time based releases (instead of feature based). The release schedule should
52 be roughly as follows:
54 <li>Set code freeze and branch creation date for 3 months after last release
55 date. Announce release schedule to the LLVM community and update the website.</li>
56 <li>Create release branch and begin release process. </li>
57 <li>Send out pre-release for first round of testing. Testing will last 7-10 days.
58 During the first round of testing, regressions should be found and fixed. Patches
59 are merged from mainline to the release branch.</li>
60 <li>Generate and send out second pre-release. Bugs found during this time will
61 not be fixed unless absolutely critical. Bugs introduce by patches merged in
62 will be fixed and if so, a 3rd round of testing is needed.</li>
63 <li>The release notes should be updated during the first and second round of
64 pre-release testing.</li>
65 <li>Finally, release!</li>
70 <!-- *********************************************************************** -->
71 <div class="doc_section"><a name="process">Release Process</a></div>
72 <!-- *********************************************************************** -->
74 <!-- ======================================================================= -->
75 <div class="doc_subsection"><a name="overview">Process Overview</a></div>
76 <div class="doc_text">
78 <li><a href="#branch">Create Release Branch</a></li>
79 <li><a href="#verchanges">Update LLVM Version </a></li>
80 <li><a href="#dist">Build the LLVM Source Distributions</a></li>
81 <li><a href="#build">Build LLVM</a></li>
82 <li><a href="#llvmgccbin">Build the LLVM GCC Binary Distribution</a></li>
83 <li><a href="#rpm">Build RPM Packages (optional)</a></li>
84 <li><a href="#check">Run 'make check'</a></li>
85 <li><a href="#test">Run LLVM Test Suite</a></li>
86 <li><a href="#prerelease">Pre-Release Testing</a></li>
87 <li><a href="#tag">Tag the LLVM Release Branch</a></li>
88 <li><a href="#updocs">Update Documentation</a></li>
89 <li><a href="#updemo">Update the LLVM Demo Page</a></li>
90 <li><a href="#webupdates">Update the LLVM Website</a></li>
91 <li><a href="#announce">Announce the Release</a></li>
96 <!-- ======================================================================= -->
97 <div class="doc_subsection"><a name="branch">Create Release Branch</a></div>
98 <div class="doc_text">
99 <p>Branch the Subversion HEAD using the following procedure:</p>
102 <p>Verify that the current Subversion HEAD is in decent shape by examining nightly
103 tester results.</p></li>
105 <p>Request all developers to refrain from committing. Offenders get commit
106 rights taken away (temporarily).</p></li>
108 <p> Create the release branch for <tt>llvm</tt>, <tt>llvm-gcc4.2</tt>, and
109 the <tt>test-suite</tt>. The branch name will be <tt>release_XX</tt>,
110 where <tt>XX</tt> is the major and minor release numbers. These branches can
111 be created without checking out anything from subversion.
114 <div class="doc_code">
116 svn copy https://llvm.org/svn/llvm-project/llvm/trunk \
117 https://llvm.org/svn/llvm-project/llvm/branches/release_<i>XX</i>
118 svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk \
119 https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_<i>XX</i>
120 svn copy https://llvm.org/svn/llvm-project/test-suite/trunk \
121 https://llvm.org/svn/llvm-project/test-suite/branches/release_<i>XX</i>
126 <p>Advise developers they can work on Subversion HEAD again.</p></li>
129 <p>The Release Manager should switch to the release branch (as all changes
130 to the release will now be done in the branch). The easiest way to do this
131 is to grab another working copy using the following commands:</p>
133 <div class="doc_code">
135 svn co https://llvm.org/svn/llvm-project/llvm/branches/release_<i>XX</i>
136 svn co https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_<i>XX</i>
137 svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_<i>XX</i>
145 <!-- ======================================================================= -->
146 <div class="doc_subsection"><a name="verchanges">Update LLVM Version</a></div>
147 <div class="doc_text">
149 After creating the LLVM release branch, update the release branches'
150 autoconf/configure.ac version from X.Xsvn to just X.X. Update it on mainline
151 as well to be the next version (X.X+1svn). Regenerated the configure script
152 for both. This must be done for both llvm and the test-suite.
154 <p>In addition, the version number of all the Bugzilla components must be
155 updated for the next release.
159 <!-- ======================================================================= -->
160 <div class="doc_subsection"><a name="dist">Build the LLVM Source Distributions</a></div>
161 <div class="doc_text">
163 Create source distributions for LLVM, LLVM GCC, and the LLVM Test Suite by
164 exporting the source from Subversion and archiving it. This can be done with
165 the following commands:
168 <div class="doc_code">
170 svn export https://llvm.org/svn/llvm-project/llvm/branches/release_<i>XX</i> llvm-X.X
171 svn export https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_<i>XX</i> llvm-gcc4.2-X.X.source
172 svn export https://llvm.org/svn/llvm-project/test-suite/branches/release_<i>XX</i> llvm-test-X.X
173 tar -cvf - llvm-X.X | gzip > llvm-X.X.tar.gz
174 tar -cvf - llvm-test-X.X | gzip > llvm-test-X.X.tar.gz
175 tar -cvf - llvm-gcc4.2-X.X.source | gzip > llvm-gcc-4.2-X.X.source.tar.gz
180 <!-- ======================================================================= -->
181 <div class="doc_subsection"><a name="build">Build LLVM</a></div>
182 <div class="doc_text">
184 Build both debug and release (optimized) versions of LLVM on all
185 platforms. Ensure the build is warning and error free on each platform.
186 Note that when building the LLVM GCC Binary, use a release build of LLVM.
190 <!-- ======================================================================= -->
191 <div class="doc_subsection"><a name="llvmgccbin">Build the LLVM GCC Binary Distribution</a></div>
192 <div class="doc_text">
194 Creating the LLVM GCC binary distribution (release/optimized) requires
195 performing the following steps for each supported platform:
200 Build the LLVM GCC front-end by following the directions in the README.LLVM
201 file. Be sure to build with LLVM_VERSION_INFO=X.X, where X is the major and
202 minor release numbers.
206 Copy the installation directory to a directory named for the specific target.
207 For example on Red Hat Enterprise Linux, the directory would be named
208 <tt>llvm-gcc4.0-2.1-x86-linux-RHEL4</tt>. Archive and compress the new directory.
213 <!-- ======================================================================= -->
214 <div class="doc_subsection"><a name="check">Run 'make check'</a></div>
215 <div class="doc_text">
217 Using the newly built llvm-gcc and llvm, reconfigure llvm to locate llvm-gcc.
218 Run <tt>make check</tt> and ensure there are no unexpected failures. If there
219 are, resolve the failures or file a bug. If there is a fix commited to mainline,
220 merge back into the release branch, and restart testing by
221 <a href="#build">re-building LLVM</a> and <a href="#build">llvm-gcc</a>. If no
222 fix will be made, XFAIL the test and commit back to the release branch.
226 Ensure that '<tt>make check</tt>' passes on all platforms for all targets. The
227 test suite must complete with "0 unexpected failures" before sending out the
228 pre-releases for testing.
232 <!-- ======================================================================= -->
233 <div class="doc_subsection"><a name="test">LLVM Test Suite</a></div>
234 <div class="doc_text">
236 Run the <tt>llvm-test</tt> suite and ensure there are no unacceptable
237 failures. Unacceptable failures are regression from the previous release
238 and (optionally) major performance regressions from the previous release.
239 If a regression is found a bug is filled, but the pre-releases may still go
243 <!-- ======================================================================= -->
244 <div class="doc_subsection"><a name="rpm">Building RPM packages (optional)</a></div>
245 <div class="doc_text">
247 You can, optionally, create source and binary RPM packages for LLVM. These may
248 make it easier to get LLVM into a distribution. This can be done with the
252 <div class="doc_code">
254 make dist # Build the distribution source tarball
255 make dist-check # Check that the source tarball can build itself.
256 cp llvm-M.m.tar.gz /usr/src/redhat/SOURCES # Required by rpmbuild
257 make srpm # for source rpm
258 make rpm # for binary rpm
263 First, use <tt>make dist</tt> to simply build the distribution. Any failures
264 need to be corrected (on the branch). Once <tt>make dist</tt> can be
265 successful, do <tt>make dist-check</tt>. This target will do the same thing as
266 the 'dist' target but also test that distribution to make sure it can build
267 itself and runs <tt>make check</tt> as well. This ensures that needed files
268 are not missing and that the src tarball can be successfully unpacked, built,
269 installed, and cleaned. Once you have a reliable tarball, you need to copy it
270 to the <tt>/usr/src/redhat/SOURCES</tt> directory which is a requirement of
271 the rpmbuild tool. The last two <tt>make</tt> invocations just run rpmbuild to
272 build either a source (<tt>srpm</tt>) or binary (<tt>rpm</tt>) RPM package.
276 <!-- ======================================================================= -->
277 <div class="doc_subsection"><a name="prerelease">Pre-Release Testing</a></div>
278 <div class="doc_text">
280 Once all testing has been completed and appropriate bugs filed, the pre-release
281 tar balls may be put on the website and the LLVM community is notified. Ask that
282 all LLVM developers test the release in 2 ways:</p>
284 <li>Download llvm-X.X, llvm-test-X.X, and the appropriate llvm-gcc4 binary.
285 Run "make check" and the full llvm-test suite (make TEST=nightly report).<li>
286 <li>Download llvm-X.X, llvm-test-X.X, and the llvm-gcc4 source. Compile
287 everything. Run "make check" and the full llvm-test suite (make TEST=nightly
290 <p>Ask LLVM developers to submit the report and make check results to the list.
291 Verify that there are no regressions from the previous release. For
292 unsupported targets, verify that make check at least is clean.</p>
294 <p>The first round of pre-release testing will be the longest. During this time,
295 all regressions must be fixed before the second pre-release is created (repeat
298 <p>If this is the second round of testing, this is only to ensure the bug fixes
299 previously merged in have not created new major problems. This is not the time
300 to solve additional and unrelated bugs. If no patches are merged in, the release
301 is determined to be ready and the release manager may move onto the next step.</p>
305 <!-- ======================================================================= -->
306 <div class="doc_subsection"><a name="tag">Tag the Release Branch</a></div>
307 <div class="doc_text">
308 <p>Tag the release branch using the following procedure:</p>
309 <div class="doc_code">
311 svn copy https://llvm.org/svn/llvm-project/llvm/branches/release_XX \
312 https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_<i>XX</i>
313 svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XX \
314 https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_<i>XX</i>
315 svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XX \
316 https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_<i>XX</i>
321 <!-- ======================================================================= -->
322 <div class="doc_subsection"><a name="updocs">Update Documentation</a></div>
323 <div class="doc_text">
325 Review the documentation and ensure that it is up to date. The Release Notes
326 must be updated to reflect bug fixes, new known issues, and changes in the
327 list of supported platforms. The Getting Started Guide should be updated to
328 reflect the new release version number tag avaiable from Subversion and
329 changes in basic system requirements. Merge both changes from mainline into
334 <!-- ======================================================================= -->
335 <div class="doc_subsection"><a name="updemo">Update the LLVM Demo Page</a></div>
336 <div class="doc_text">
338 The LLVM demo page must be updated to use the new release. This consists of
339 using the llvm-gcc binary and building LLVM. Update the website demo page
340 configuration to use the new release.</p>
343 <!-- ======================================================================= -->
344 <div class="doc_subsection"><a name="webupdates">Update the LLVM Website</a></div>
345 <div class="doc_text">
347 The website must be updated before the release announcement is sent out. Here is
350 <li> Check out the <tt>website</tt> module from CVS. </li>
351 <li> Create a new subdirectory X.X in the releases directory. </li>
352 <li> Commit the <tt>llvm</tt>, <tt>test-suite</tt>, <tt>llvm-gcc</tt> source,
353 and <tt>llvm-gcc</tt> binaries in this new directory. </li>
354 <li> Copy and commit the <tt>llvm/docs</tt> and <tt>LICENSE.txt</tt>
355 files into this new directory. The docs should be built with BUILD_FOR_WEBSITE=1.</li>
356 <li> Commit the index.html to the release/X.X directory to redirect (use from previous
358 <li> Update the <tt>releases/download.html</tt> file with the new release. </li>
359 <li>Update the <tt>releases/index.html</tt> with the new release and link to
360 release documentation.</li>
361 <li> Finally, update the main page (<tt>index.html</tt> and sidebar) to
362 point to the new release and release announcement. Make sure this all gets
363 commited back into Subversion.</li>
367 <!-- ======================================================================= -->
368 <div class="doc_subsection"><a name="announce">Announce the Release</a></div>
369 <div class="doc_text">
370 <p>Have Chris send out the release announcement when everything is finished.</p>
373 <!-- *********************************************************************** -->
374 <div class="doc_section"><a name="dist_targets">Distribution Targets</a></div>
375 <!-- *********************************************************************** -->
377 <!-- ======================================================================= -->
378 <div class="doc_subsection">Overview</div>
379 <div class="doc_text">
381 The first thing you need to understand is that there are multiple make targets
382 to support this feature. Here's an overview, we'll delve into the details
387 <li><b>distdir</b> - builds the distribution directory from which the
388 distribution will be packaged</li>
389 <li><b>dist</b> - builds each of the distribution tarballs (tar.gz,
390 tar.bzip2, .zip). These can be built individually as well, with separate
392 <li><b>dist-check</b> - this is identical to <tt>dist</tt> but includes a
393 check on the distribution that ensures the tarball can: unpack
394 successfully, compile correctly, pass '<tt>make check</tt>', and pass
395 '<tt>make clean</tt>'.</li>
396 <li><b>dist-clean</b>- this just does a normal clean but also cleans up the
397 stuff generated by the other three <tt>dist</tt> targets (above).</li>
401 Okay, that's the basic functionality. When making a release, we want to ensure
402 that the tree you build the distribution from passes
403 <tt>dist-check</tt>. Beyond fixing the usual bugs, there is generally one
404 impediment to making the release in this fashion: missing files. The
405 <tt>dist-check</tt> process guards against that possibility. It will either
406 fail and that failure will indicate what's missing, or it will succeed meaning
407 that it has proved that the tarballs can actually succeed in building LLVM
408 correctly and that it passes <tt>make check</tt>.
412 <!-- ======================================================================= -->
414 <div class="doc_subsection">distdir</div>
415 <div class="doc_text">
417 This target builds the distribution directory which is the directory from
418 which the tarballs are generated. The distribution directory has the same
419 name as the release, e.g. LLVM-1.7). This target goes through the following
424 <li>First, if there was an old distribution directory (for the current
425 release), it is removed in its entirety and you see <tt>Removing old
427 <li>Second, it issues a <tt>make all ENABLE_OPTIMIZED=3D1</tt> to ensure
428 that the everything in your tree can be built in release mode. Often
429 times there are discrepancies in building between debug and release
430 modes so it enforces release mode first. If that fails, the
431 <tt>distdir</tt> target fails too. This is preceded by the message
432 <tt>Making 'all' to verify build</tt>.</li>
433 <li>Next, it traverses your source tree and copies it to a new directory
434 that has the name of the release (<tt>LLVM-M.m</tt> in our current
435 case). This is the directory that will get tar'd. It contains all the
436 software that needs to be in the distribution. During the copying
437 process, it omits generated files, SVN directories, and any other
438 "cruft" that's in your build tree. This is done to eliminate the
439 possibility of huge distribution tarballs that include useless or
440 irrelevant stuff in them. This is the trickiest part of making the
441 distribution. Done manually you will either include stuff that
442 shouldn't be in the distribution or exclude stuff that should. This
443 step is preceded by the message <tt>Building Distribution Directory
445 <li>The distribution directory is then traversed and all <tt>CVS</tt> or
446 <tt>.svn</tt> directories are removed. You see: <tt>Eliminating CVS/.svn
447 directories from distribution</tt></li>
448 <li>The recursive <tt>dist-hook</tt> target is executed. This gives each
449 directory a chance to modify the distribution in some way (more on this
451 <li>The distribution directory is traversed and the correct file
452 permissions and modes are set based on the type of file.</li>
456 To control the process of making the distribution directory correctly, each
457 Makefile can utilize two features:
461 <li><b><tt>EXTRA_DIST</tt></B> - this make variable specifies which files
462 it should distribute. By default, all source files are automatically
463 included for distribution as well as certain <tt>well known</tt> files
464 (see DistAlways variable in Makefile.rules for details). Each Makefile
465 specifies, via the <tt>EXTRA_DIST</tt> variable, which additional files
466 need to be distributed. Only those files that are needed to build LLVM
467 should be added to <tt>EXTRA_DIST</tt>. <tt>EXTRA_DIST</tt> contains a
468 list of file or directory names that should be distributed. For example,
469 the top level Makefile contains <tt>EXTRA_DIST := test llvm.spec
470 include</tt>. This means that in addition to regular things that are
471 distributed at the top level (<tt>CREDITS.txt, LICENSE.txt</tt>, etc.)
472 the distribution should contain the entire <tt>test</tt> and
473 <tt>include</tt> directories as well as the <tt>llvm.spec</tt> file.</li>
474 <li><b><tt>dist-hook</tt></B> - this make target can be used to alter the
475 content of the distribution directory. For example, in the top level
476 Makefile there is some logic to eliminate files in the <tt>include</tt>
477 subtree that are generated by the configure script. These should not be
478 distributed. Similarly, any <tt>dist-hook</tt> target found in any
479 directory can add or remove or modify things just before it gets
480 packaged. Any transformation is permitted. Generally, not much is
485 You will see various messages if things go wrong:
489 <li>During the copying process, any files that are missing will be flagged
490 with: <tt>===== WARNING: Distribution Source 'dir/file' Not Found!</tt>
491 These must be corrected by either adding the file or removing it from
492 <tt>EXTRA_DIST</tt>.</li>
493 <li>If you build the distribution with <tt>VERBOSE=1</tt>, then you might
494 also see: <tt>Skipping non-existent 'dir/file'</tt> in certain cases
495 where it's okay to skip the file.</li>
496 <li>The target can fail if any of the things it does fail. Error messages
497 should indicate what went wrong.</li>
501 <!-- ======================================================================= -->
502 <div class="doc_subsection">dist</div>
503 <div class="doc_text">
505 This target does exactly what <tt>distdir</tt> target does, but also includes
506 assembling the tarballs. There are actually four related targets here:
510 <li><b><tt>dist-gzip</tt></b>: package the gzipped distribution tar
511 file. The distribution directory is packaged into a single file ending
512 in <tt>.tar.gz</tt> which is gzip compressed.</li>
513 <li><b><tt>dist-bzip2</tt></b>: package the bzip2 distribution tar file.
514 The distribution directory is packaged into a single file ending in
515 <tt>.tar.bzip2</tt> which is bzip2 compressed.</li>
516 <li><b><tt>dist-zip</tt></b>: package the zip distribution file. The
517 distribution directory is packaged into a single file ending in
518 <tt>.zip</tt> which is zip compressed.</li>
519 <li><b><tt>dist</tt></b>: does all three, dist-gzip, dist-bzip2,
524 <!-- ======================================================================= -->
525 <div class="doc_subsection">dist-check</div>
526 <div class="doc_text">
528 This target checks the distribution. The basic idea is that it unpacks the
529 distribution tarball and ensures that it can build. It takes the following
534 <li>It depends on the <tt>dist-gzip</tt> target which, if it hasn't already
535 been built, builds the gzip tar bundle (see dist and distdir
537 <li>removes any pre-existing <tt>_distcheckdir</tt> at the top level.</li>
538 <li>creates a new <tt>_distcheckdir</tt> directory at the top level.</li>
539 <li>creates a <tt>build</tt> subdirectory and an <tt>install</tt>
540 subdirectory under <tt>_distcheckdir</tt>.</li>
541 <li>unzips and untars the release tarball into <tt>_distcheckdir</tt>,
542 creating <tt>LLVM-1.7</tt> directory (from the tarball).</li>
543 <li>in the build subdirectory, it configures with appropriate options to
544 build from the unpacked source tarball into the <tt>build</tt> directory
545 with installation in the <tt>install</tt> directory.</li>
546 <li>runs <tt>make all</tt></li>
547 <li>runs <tt>make </tt><tt>check</tt></li>
548 <li>runs <tt>make install</tt></li>
549 <li>runs <tt>make uninstall</tt></li>
550 <li>runs <tt>make dist</tt></li>
551 <li>runs <tt>make clean</tt></li>
552 <li>runs <tt>make dist-clean</tt></li>
556 If it can pass all that, the distribution will be deemed distribution worth y
560 <pre>===== LLVM-1.7.tar.gz Ready For Distribution =====</pre>
563 This means the tarball should then be tested on other platforms and have the
564 nightly test run against it. If those all pass, THEN it is ready for
569 A note about disk space: using <tt>dist-check</tt> will easily triple the
570 amount of disk space your build tree is using. You might want to check
571 available space before you begin.
575 <!-- ======================================================================= -->
576 <div class="doc_subsection">dist-clean</div>
577 <div class="doc_text">
579 In addition to doing a normal <tt>clean</tt>, this target will clean up the
580 files and directories created by the distribution targets. In particular the
581 distribution directory (<tt>LLVM-X.X</tt>), check directory
582 (<tt>_distcheckdir</tt>), and the various tarballs will be removed. You do
583 this after the release has shipped and you no longer need this stuff in your
588 <!-- *********************************************************************** -->
591 <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
592 src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
593 <a href="http://validator.w3.org/check/referer"><img
594 src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
595 <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
597 Last modified: $Date$