- <p>
- Merge any work done on branches intended for release into mainline. Finish and
- commit all new features or bug fixes that are scheduled to go into the
- release. Work that is not to be incorporated into the release should not be
- merged from branchs or commited from developer's working directories.
- </p>
-
- <p>
- From this point until the release branch is created, developers should
- <em>not</em> commit changes to the <tt>llvm</tt> and <tt>llvm-gcc</tt>
- Subversion repositories unless it is a bug fix <em>for the release</em>.
- </p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="deps">Make LibDeps.txt</a></div>
-<div class="doc_text">
- <p>
- Rebuild the <tt>LibDeps.txt</tt> target in <tt>utils/llvm-config</tt>. This
- makes sure that the <tt>llvm-config</tt> utility remains relevant for the
- release, reflecting any changes in the library dependencies.
- </p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="settle">Settle Subversion HEAD</a></div>
-<div class="doc_text">
- <p>
- Use the nightly test reports and 'make check' (deja-gnu based tests) to
- ensure that recent changes and merged branches have not destabilized LLVM.
- Platforms which are used less often should be given special attention as they
- are the most likely to break from commits from the previous step.
- </p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="tag">Subversion Tag And Branch</a></div>
-<div class="doc_text">
- <p>Tag and branch the Subversion HEAD using the following procedure:</p>