From 1a2e110470db6504a70ed310493ae85efb4bd389 Mon Sep 17 00:00:00 2001 From: Reid Spencer Date: Tue, 11 Apr 2006 06:21:25 +0000 Subject: [PATCH] Flesh out the documentation a little bit more. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@27584 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/HowToReleaseLLVM.html | 62 +++++++++++++++++++++++++++++++++----- 1 file changed, 54 insertions(+), 8 deletions(-) diff --git a/docs/HowToReleaseLLVM.html b/docs/HowToReleaseLLVM.html index c0fe8da4c4c..0e1847eddf7 100644 --- a/docs/HowToReleaseLLVM.html +++ b/docs/HowToReleaseLLVM.html @@ -38,6 +38,7 @@ deficient.

  1. Merge Branches
  2. +
  3. Settle LLVM HEAD
  4. Build LLVM
  5. Run 'make check'
  6. Run LLVM Test Suite
  7. @@ -51,27 +52,45 @@ deficient.

    -

    Merge any work done on branches intended for release into mainline.

    +

    Merge any work done on branches intended for release into mainline. Work that +is not to be incorporated into the release should not be merged from the branch. +

    +
    + + + +
    +

    Use the nightly test reports, and 'make check' (deja-gnu based tests) to + increase the quality of LLVM and ensure that merged branches have not + destabilized LLVM.

    -

    Build LLVM

    +

    Build both debug and release versions of LLVM on all platforms. Ensure + build is warning and error free on each platform.

    Run make check and ensure there are no unexpected failures. If - there are, resolve the failures and go back to step 2.

    + there are, resolve the failures and go back to step 2. + Ensure that 'make check' passes on all platforms for all targets. If certain + failures cannot be resolved before release time, determine if marking them + XFAIL is appropriate. If not, fix the bug and go back. The test suite must + complete with "0 unexpected failures" for release. +

    Run the llvm-test suite and ensure there are no unacceptable failures. - If there are, resolve the failures and go back to step 2.

    + If there are, resolve the failures and go back to step 2. The test suite + should be run in Nightly Test mode. All tests must pass. If they do not, + investigate and go back to settling CVS HEAD.

    @@ -83,21 +102,48 @@ deficient.

-
CVS Tag
+
CVS Tag And Branch
-

Tag the release.

+

Tag and branch the CVS HEAD using the following procedure:

+
    +
  1. Request all developers to refrain from committing. Offenders get commit + rights taken away (temporarily).
  2. +
  3. Tag the cvs HEAD with "ROOT_RELEASE_XX" where XX is the major and minor + release numbers (you can't have . in a cvs tag name). So, for Release 1.2, + XX=12 and for Release 1.10, XX=110.
  4. +
  5. Immediately create a cvs branch based on the ROOT_RELEASE tag. This is + where the release distribution will be created.
  6. +
  7. Advise developers they can work on CVS HEAD again.
  8. +
  9. Ensure all subsequent building and fixing is done on this branch.
Run 'make dist'
-

Build the distribution, ensuring it is installable and working

+

Build the distribution, ensuring it is installable and working. This is a + two step process. First, use "make dist" to simply build the distribution. Any + failures need to be corrected (on the branch). Once "make dist" can be + successful, do "make dist-check". This target will do the same thing as the + 'dist' target but also test that distribution to make sure it works. This + ensures that needed files are not missing and that the src tarball can be + successfully unbacked, built, installed, and cleaned. This two-level testing + needs to be done on each target platform.

Release
-

Release the distribution tarball to the public.

+

Release the distribution tarball to the public. This consists of generating + several tarballs. The first set, the source distributions, are automatically + generated by the "make dist" and "make dist-check". There are gzip, bzip2, and + zip versions of these bundles.

+

The second set of tarballs is the binary release. When "make dist-check" + succeeds, it will have created an _install directory into which it installed + the binary release. You need to rename that directory as "llvm" and then + create tarballs from the contents of that "llvm" directory.

+

Finally, use rpm to make an rpm package based on the llvm.spec file. Don't + forget to update the version number, documentation, etc. in the llvm.spec + file.