Get Support

Get Involved



How to build a release of Apache

Alexei Kosut <>

Ralf S. Engelschall <>

Jim Jagielski <>

Ken Coar <>

Martin Kraemer <>

This document has been obsoleted in httpd-2.0 by the httpd/site/trunk/tools/ script. It does everything for you. At some point, we may come back and update this document. So, in the meantime, ignore this and use that script for Apache 2.0 rolls.

This document describes the typical release cycle the release manager has to step through when creating a new Apache release. It is written down as a step-by-step instruction list and should be followed exactly as specified to avoid problems or inconsistencies both in the created tarballs and the source repository.

How to build an Apache Unix release

Note:The below assumes that you are using ssh to login to your account. If you are "rolling the tarball" remotely, the differences will be noted.

Important:Once tagged and the tarball is rolled, there is no going back. If there are problems with the tarball, the version number (either the rev-level or beta-level) must be bumped resulting in a new tag, tarball and release.

  1. Checkout the Apache source if needed into a scratch directory:

    For Apache 2. X :

    $ cvs checkout -r APACHE_2_ X _BRANCH -Pd httpd-2. X httpd-2.0

    $ cd httpd-2. X /srclib

    $ cvs checkout apr apr-util

    Omit the -r APACHE_2_ X _BRANCH flag for the current development branch (e.g. 2.1-dev.) The current development branch always sits at cvs HEAD.

  2. cd into the apache CVS tree.

    $ cd apache-1. X


    $ cd httpd-2. X

  3. Adjust Announcement to taste.

    A prototype Announcement is included in the main CVS source tree. This file should be updated to reflect the current state of affairs concerning the release. For example, the Release Version should reflect what is actually being announced. Also, the key enhancements of the Release should be noted.

    $ vi Announcement

    $ cvs commit Announcement

    Note: This document is also present in the httpd-dist cvs module, both in HTML and plain text form. You may want to create one version out of the other.

  4. Change the version number to indicate a release.

    For Apache 2.0:

    Change SERVER_BASEREVISION ininclude/httpd.hfrom <code>2. *X* -dev</code>'' to2. X ''. Then also change APACHE_RELEASE in the same file from <code>2 *XXYY0* 00</code>'' to2 XXYY1 00''.

Note:until Apache 2.0 is of general release quality, module magic numbers are not enforced. You must editinclude/ap_mmn.hand bump the MODULE_MAGIC_NUMBER_MAJOR prior to rolling the tarball, to assure beta testers are testing the modules.This policy will be retracted, and coders will be reponsible for mmn bumps, once Apache 2.0 is officially released.

  1. Make sure your PGP keys are already present in the KEYS file. If they are not, extract your public key using the `pgp -kxa'' command, add them to theKEYS` file and commit it before tagging.

  2. Tag the sources for this release:

    ( *note: be sure to tag the whole thing, not just src * !)

    $ cvs tag APACHE_1_ X_Y

    For Apache 2.0:

    $ cvs tag APACHE_2_ X_Y

  3. Make an export version of the distribution: (this creates a second subdirectoryapache-Z. X.Y for the exported version beside the existing CVS tree inapache-Z. X )

    For Apache 2.0:

    $ cd..

    $ umask 022

    $ cvs export -r APACHE_2_ X_Y -d apache_2. X.Y httpd-2. X

    $ cd apache_2. X.Y /srclib

    $ cvs export -r APACHE_2_ X_Y apr apr-util

  4. Note:There is a known problem using cvs export remotely with cvs-1.9 and later. If this affects you, you will need to do a checkout instead:

    $ umask 022

    $ cvs checkout -r APACHE_2_ X_Y -d apache_2. X.Y httpd-2. X

    $ cd apache_2. X.Y /srclib

    $ cvs checkout -r APACHE_2 X_Y apr apr-util

  5. Make sure the master site's FAQ is up-to-date:

    $ (cd /www/ ; cvs update)

  6. Extract the FAQ as a single file, as it appears on the Web:

    $ links -source > htdocs/manual/misc/FAQ.html

  7. Create the configuration files:

    For Apache 2.0:

    Create ./configure file, and remove all symlinks


    $ rm -f ltconfig config.sub config.guess

    $ cp /usr/local/share/libtool/ltconfig.

    $ cp /usr/local/share/libtool/

    $ cp /usr/local/share/libtool/config.sub.

    $ cp /usr/local/share/libtool/config.guess.

  8. Remove STATUS , RULES.CVS , src/INDENT , the multi-part FAQ, various .cvsignore and the developer's test subdirectories. Depending on which version you are releasing, not all of these files will be in the repository:

    $ rm STATUS RULES.CVS src/INDENT htdocs/manual/misc/FAQ-*.html

    $ find. -name ".cvsignore" -exec rm {} \;

    $ find. -type d -name "test" -exec rm -Rf {} \;

  9. Note:If you needed to do a checkout instead of a export , you will also need to remove the CVS administrative files:

    $ find. -type d -name "CVS" -exec rm -rf {} \;

  10. Roll the distribution tarball:

    $ tar cvf apache_ Z.X.Y.tar apache_ Z.X.Y

  11. Make the final packed distribution files:

    $ cp -p apache_ Z.X.Y.tar xapache_ Z.X.Y.tar

    $ gzip -9 apache_ Z.X.Y.tar

    $ mv xapache_ Z.X.Y.tar apache_ Z.X.Y.tar

    $ compress apache_ Z.X.Y.tar

  12. Test the packed tar files and check for errors:

    $ gunzip -c apache_ Z.X.Y.tar.gz | tar tvf -

    (or simply: $ tar tvzf apache_ Z.X.Y.tar.gz )

    $ uncompress <apache_ Z.X.Y.tar.Z | tar tvf -

  13. Sign the distribution files:

    $ pgp -sba apache_ Z.X.Y.tar.gz

    $ pgp -sba apache_ Z.X.Y.tar.Z

  14. Note:Be sure your PGP key is already in the KEYS file!

  15. Test the tarball signatures:

    $ pgp apache_ Z.X.Y.tar.gz.asc apache_ Z.X.Y.tar.gz

    $ pgp apache_ Z.X.Y.tar.Z.asc apache_ Z.X.Y.tar.Z

  16. Remember the CHANGES file:

    $ cp apache_ Z.X.Y /src/CHANGES./CHANGES_ Z.X

  17. Cleanup:

    (this deletes the export tree: it is now no longer required. We still need the CVS tree, see below)

    $ rm -fr apache_ Z.X.Y

  18. Make the tarball available for testing purposes (in ) by committing the generated release tarballs and signatures to the repository.

  19. Bump the version number to the next version and indicate we are in development.

    cd back into the CVS tree location.

    $ cd apache- Z.X For Apache 2.0:

    Change SERVER_BASEREVERSION in include/httpd.h from <code>2. *X.Y* </code>'' to2. X.(Y+1) -dev'' and change APACHE_RELEASE to1 XX(YY+1) 000.

    Edit theSTATUSfile and update the status for the tagged apache_1. X.Y version, and add a header line for the new apache_1. X.(Y+1) version

    $ vi STATUS

    $ cvs commit STATUS

    $ cd..

    Finally, add a new line ``Changes with Apache 1. X.(Y+1) :'' to the head of theCHANGESfile for the forthcoming fixes in the new version.

    $ vi include/httpd.h \<br>

    $ cvs commit include/httpd.h \<br>

    $ cd..

  20. Cleanup:

    (delete the CVS tree, after verification that it does not contain any uncommitted changes)

    $ cvs release -d apache- Z.X

Now wait for the group to test and approve the tarball.

Final release steps

Note:Do not continue with the rest of these instructions until the group really approves the tarball!

  1. Make the distribution available (in ) by svn mv'ing the files from to the repository.

  2. If binary builds are already built and tested at this point, you can add them in svn under the distribution tree branches{OS}/.

  3. Checkout the httpd-dist site , if needed, into a scratch directory:

    $ cvs -d checkout -P httpd-dist

  4. Change directory into httpd-dist

    $ cd httpd-dist/

  5. Edit the files and as well as and its plaintext equivalent plus the file (which defines the AddDescription comments) from the httpd-dist CVS tree as required (all in the subdirectory). The Announcement.* files should be based on the Announcement file in the tagged CVS tree. For Apache 2.0, Announcement should be replaced with Announcement2 :

    $ vi README.html HEADER.html Announcement.html Announcement.txt.htaccess

  6. Commit the changes:

    $ cvs commit README.html HEADER.html Announcement.html Announcement.txt.htaccess

    $ cd../..

  7. Checkout the httpd site if needed into a scratch directory:

    $ cvs -d checkout httpd-site

  8. cd into the httpd-site xdocs tree.

    $ cd httpd-site/xdocs/

  9. Edit the page from the httpd-site CVS tree as required:

    $ vi index.xml

  10. Commit the changes:

    $ cd..

    $./ # Check result before continuing

    $ cvs commit

  11. Update the checked-out versions of the httpd-dist documents for the web server:

    $ umask 002

    $ cd /www/

    $ cvs update -dP

  12. Create an empty directory for future patches:

    $ mkdir patches/apply_to_1. X.Y

  13. Update the checked-out version of the httpd-site index.html page for the web server:

    $ umask 002

    $ cd /www/

    $ cvs update -dP

At this point, the web-sites reflect the existance of the new release.

As it is going to be some 24hrs before any announcement goes out (to make sure that the mirror's have at least a chance of grabbing a copy) this is also the right time to mail and ask people to upload and move into position any binaries they have build and vetted.

Announcing a New Release

Once a release is built and released , it is time to announce it to the world.

  1. Grab the prepared Announcement:

    You can grab either the Announcement file in the tagged tree, or the Announcement.txt file from the web-site.

  2. Post the Announcement:

    Once the tarball is built, give the mirrors a good 24 hours to get up to sync. This is really important if this this a final (i.e.: non-beta) release.

  3. Now, Announcement should be posted to the following places (please note that a mail send to must have your address set as its 'From' address, otherwise it won't pass the anti-spam filter):

  4. Unmoderated UseNet newsgroups (should be crossposted)

    • comp.infosystems.www.servers.unix


    • comp.infosystems.www.servers.misc

    • de.comm.infosystems.www.servers

  5. Moderated UseNet newsgroups (do not crosspost)

    • comp.infosystems.www.announce
  6. Mailing Lists





  7. Make sure that Announcement.txt and Announcement.html in httpd-dist are updated to include these changes.

  8. Bask in the glow