antliscence/ReleaseInstructions

Instructions for making a Release:

Authors: Conor MacNeill
         Stefan Bodewig
         Magesh Umasankar
         Antoine Levy-Lambert

Note: This document was updated in the context of releasing Ant
      1.9.7 which was the first release cut from the 1.9.x branch.
      Please interpret the branch names, tags, etc. according to
      your context.

      It reflects the way Stefan prefers to cut the release, parts of
      this process haven't even been discussed on the dev list and may
      change with later releases.

1.  Propose a release plan for vote.  This should set out the timetable for
    the release under ideal circumstances.  

    In reality, you send a note to the list that you intend to cut the
    release and wait for a few days whether anybody objects.

    We haven't created extra branches for releases in a long time and
    with our new 1.9.x LTS policy there is a permanent branch for
    Java5 compatible releases anyway. So no extra branch for the
    releases is needed.

    This document assumes you are familiar with git
    http://git-scm.com/book/en/v2/
    may be a good guide if you are not.

2.  Ensure you have all the external libraries that Ant uses in your
    lib/optional directory.  All dependencies are either provided by
    JDK 1.5.0 or downloadable using
    ant -f fetch.xml -Ddest=optional
    To find out whether you have all the libraries you need, execute
    the build with -verbose option and scan for lines beginning with
    "Unable to load...". 

    Also check the NOTICE file to make sure it has the correct
    Copyright year. If the year isn't right, update that file to use
    the right year and commit and push the change upstream, before
    starting any release process.

3.  We don't want tags for failed votes to end up on our branches so
    the release is first created from a detached head.

    Checkout the HEAD of the 1.9.x branch as a detached head:

    $ git checkout 1.9.x^0

4.  Make sure that your directory tree is clean by running git status.
    Some tests leave behind leftovers which end up in the source
    distribution otherwise.

5.  Set the version number in several files to the required new
    versions. These are:

    * manual/cover.html (version should already be correct here)
    * manual/credits.html  (version should already be correct here)
    * build.xml properties : project.version,manifest-version,pom.version
    * POM files under src/etc/poms and subdirectories
      if you've got mvn installed

      $ mvn versions:set -DnewVersion=1.9.7 -DgenerateBackupPoms=false

      inside src/etc/poms should do the trick.

    * ivy.xml in release subdirectory (version should already be correct here)
    * WHATSNEW (version should already be correct here)
    * src/etc/testcases/taskdefs/conditions/antversion.xml (version should already be correct here)

6.  Next bootstrap, build and run the tests.

    $ ./bootstrap.sh
    $ ./build.sh
    $ ./build.sh test
    # if you've got maven installed
    $ mvn -f src/etc/poms/pom.xml -DskipTests  package

7.  Then build the distribution. It is important that this be a clean
    build.

    # clean
    $ rm -rf bootstrap build dist distribution java-repository target
    $ ./build.sh dist-lite
    $ ./dist/bin/ant -nouserlib -lib lib/optional distribution

    build.xml specifies that the code should be compiled with
    source=1.5 and target=1.5.

8.  Commit your changes, tag them, push them.

    $ git tag -s -m "Tagging RC1 for version 1.9.7 of Ant" ANT_197_RC1
    $ git push --tags

9.  Ensure that the GPG key you use is inside the KEYS file in Ant's
    git repository
    <https://git-wip-us.apache.org/repos/asf?p=ant-antlibs-common.git;a=blob;f=KEYS;h=dc62b011b1b429bd6de913f8f2bce79b715f96db;hb=HEAD>
    - and that you copy the KEYS file to /www/www.apache.org/dist/ant

    Also make sure you have sent the key that you use to a public
    keyserver.

10. Sign the distribution files

    There are two aproaches, one uses Ant and a few libraries, the
    other requires you to run gnupg manually. The first version didn't
    work for Stefan when he built the first release candidate for
    1.9.7.

    a. Using the script release/signit.xml

    This script requires using commons-openpgp to sign the artefacts,

    This tool can be checked out from 
    http://svn.apache.org/repos/asf/commons/sandbox/openpgp/trunk
    You have to build it using maven.

    $ mvn install

    The script assumes commons-openpgp (and bouncycastle) are in your
    local maven repository.

    You can create a property file gnupg.properties in your home directory 
    with your key id - like

    keyid=5F6B8B72

    or use -Dkeyid

    and pass your key passphrase on the command line with -Dpassword=****

    $ ./build.sh -f release/signit.xml -Dpassword=****

    b. Using gpg

    $ for i in distribution/*/*.zip distribution/*/*.gz distribution/*/*.bz2; do gpg --use-agent --detach-sign --armor $i; done
    $ for i in java-repository/org/apache/ant/ant*/*/*.jar java-repository/org/apache/ant/ant*/*/*.pom; do gpg --use-agent --detach-sign --armor $i; done

11. Convert the part of the WHATSNEW file covering the changes
    since the last release into HTML for the README file on the
    website. See the previous release directories for examples of these files.

    Use the target txt2html of docs.xml

    $ ./build.sh -f docs.xml txt2html

    This target generates a file build/html/WHATSNEW.html

    Add an html head element with a title like "Release Notes of Apache Ant
    1.9.7" (from the default txt2html)

    Cut all sections about previous releases to keep only the current release,
    and save as  RELEASE-NOTES-1.9.7.html inside the distribution folder.

    Copy the contents of RELEASE-NOTES-1.9.7.html also into README.html

12. The distribution is now ready to go.
    Create a SVN sandbox on your computer with https://dist.apache.org/repos/dist/dev/ant in it
    Copy the distribution folder to the location of the sandbox.
    svn add the files and commit into https://dist.apache.org/repos/dist/dev/ant

13. Upload the maven artifacts located under java-repository/org/apache/ant
    these artifacts comprise currently for each ant jar of one POM
    file, the corresponding jar file and the corresponding GPG
    signatures (x.pom, x.jar, x.pom.asc, x.jar.asc) SHA1 are
    generated by ivy during the upload

    to

      https://repository.apache.org (nexus repository)

    using the build file release/upload.xml - this requires Ivy

      $ ./build.sh -Dupload.user=foo -Dupload.password=secret -lib location_of_ivy_jar -f release/upload.xml

    After the upload, you need to access the web interface of nexus
    under https://repository.apache.org login using your Apache
    credentials in the left pane, below "build promotion", click on
    the "Stagings Repositories" links expand org.apache.ant select the
    checkbox next to the upload that you just did click the button
    "Close" on the top of the table listing the uploads make a note of
    the location of the staging repository for the vote email

14. Once this is committed send a release vote email on dev@ant.
    The email will typically mention :
       - the git tag for the release including commit hash,
       - the location of the tarballs, including revision number in
         dist.apache.org repository
       - the URL for the maven artifacts

    The vote will only pass if at least three PMC members have voted +1
    and more +1s than -1s have been cast.  The vote will run for 3 days.

15. If the vote fails, address the problems and recreate the next RC
    build.

16. Once the vote has passed, tag the last RC created with the final tag

    $ git tag -s -m "Tagging version 1.9.7 of Ant" rel/1.9.7 HASH_OF_LAST_RC
    $ git push --tags

17. The distrib artifacts should be published the apache dist. It is
    managed via svnpubsub so the release should be committed to the
    subversion repository
    https://dist.apache.org/repos/dist/release/ant/.

    * commit the new release files to

      https://dist.apache.org/repos/dist/release/ant/[source|binaries|manual].

    * Make https://dist.apache.org/repos/dist/release/ant/README.html
      point to the new RELEASE-NOTES or a copy of it.

    * release the maven artifacts using the web interface of nexus under https://repository.apache.org
      login using your Apache credentials
      in the left pane, below "build promotion", click on the "Stagings Repositories" links
      expand org.apache.ant 
      select the checkbox next to the upload that you just did
      and click the button "Release".
      4 hours later, the artifacts will be in the maven central repository.
      
18. Update the Apache Reporter System

    https://reporter.apache.org/addrelease.html?ant

19. Address the available version tags in BugZilla. Create new
    milestone 1.9.8 and version 1.9.7.

20. Add a new release tag to doap_Ant.rdf in Ant's site.

21. checkout the 1.9.x branch, merge the tag but don't push the
    commit

    $ git checkout 1.9.x
    $ git merge rel/1.9.7

    Set the version number in several files to the required version of
    the next 1.9.x release. These are:

    * manual/cover.html
    * manual/credits.html
    * build.xml properties : project.version,manifest-version,pom.version

      project.version property in build.xml gets bumped to
      [newversion]alpha, for example 1.9.8alpha

      manifest-version gets bumped to the exact next release number
      for example 1.9.8.

      pom.version gets bumped to [newversion]-SNAPSHOT
      for example 1.9.8-SNAPSHOT.

    * POM files under src/etc/poms and subdirectories
      if you've got mvn installed

      $ mvn versions:set -DnewVersion=1.9.8-SNAPSHOT -DgenerateBackupPoms=false

      inside src/etc/poms should do the trick.

    * ivy.xml in release subdirectory
    * WHATSNEW (add a new section)
    * src/etc/testcases/taskdefs/conditions/antversion.xml

    Amend the merge commit

    $ git add -u
    $ git commit -a --amend
    $ git push

22. checkout the master branch, merge the 1.9.x branch

    $ git checkout master
    $ git merge 1.9.x
    $ git push

23. wait a few hours for the mirrors to catch up

24. Update the ant.apache.org site :

    The website is managed here: https://svn.apache.org/repos/asf/ant/site/ant/

    Copy the manual of the release into the production folder - since
    the site still uses svn and Ant proper uses git there currently is
    no way to use the scm for this.

    Update the following files for version number:

    * source/antnews.xml (Announcement)
    * source/faq.xml (Ant's history details - not for betas)
    * source/index.xml (Announcement, latest release details, link to
    manual under "Documentation")
    * source/srcdownload.xml
    * source/bindownload.xml
    * source/manualdownload.xml

    Generate the html files by invoking 'ant'
    Commit the modified/generated files in the 'production' folder, it will go
    live on ant.apache.org in a matter on seconds.

25. At this point in time, the release is done and announcements are made.
    PGP-sign your announcement posts.

    Apache mailing lists that should get the announcements:
    announce@apache.org, dev@ant and user@ant.

26. You can now reacquaint yourself with your family and friends.

27. After a few days "svn rm" the older release artifacts and release
    notes from https://dist.apache.org/repos/dist/release/ant/

Related Information

http://www.apache.org/dev/#releases
http://commons.apache.org/releases/index.html
http://wiki.apache.org/commons/SigningReleases

Files containing version information
------------------------------------

   * manual/cover.html
   * manual/credits.html
   * build.xml properties : project.version,manifest-version,pom.version
   * POM files under src/etc/poms and subdirectories
   * ivy.xml in release subdirectory
   * WHATSNEW
   * src/etc/testcases/taskdefs/conditions/antversion.xml

cover.html, credits.html, POM files, antversion.xml should be 
adjusted for the [newversion] right after the build and tagging 
of the release

build.xml
---------

  right before a release :

    the project.version gets bumped to the exact release
    number, for instance 1.9.5

  right after a release :
 
    project.version property in build.xml gets bumped to
    [newversion]alpha, for example 1.9.6alpha

    manifest-version gets bumped to the exact next release number
    for example 1.9.6

    pom.version gets bumped to [newversion]-SNAPSHOT