Making a release


Making a release

Requirements

Requirements for making a release are similar to the requirements for building from source, except that sun jdk 1.6 and ant 1.7 are required.

Procedure

1. Check the files which needs to be updated for the release.

On the trunk, check that files which require update for the release are up to date.
This includes particularly:
RELEASE_NOTES
CHANGES
README

2. Create a release branch

This will allow to work separately from other developers, in case you need any last modification. 
svn copy https://svn.apache.org/repos/asf/ant/ivy/core/trunk \
           https://svn.apache.org/repos/asf/ant/ivy/core/branches/2.0.0-beta1 \
      -m "Creating a release branch for 2.0.0-beta1."

3. Check out the branch

svn co https://svn.apache.org/repos/asf/ant/ivy/core/branches/2.0.0-beta1 ivy-2.0.0-beta1

4. Add Ivy xsd file.

You need to store the current ivy xml schema in the documentation, so that it will later be accessible on public web site. To do so, run the following command in the directory in which you checked out the release branch: 
ant -f build-release.xml release-xsd

5. Add release note page in the documentation.

Open the file doc/index.html with your favorite browser, and click on the plus button in the upper right. Choose "Release Notes" as title, and "release-notes" as page id.

Then edit the page (hit the first button at the upper right), and copy the content of the RELEASE_NOTES file. You can also add the announcement for the release if it's already ready.

Move the page up in the TOC using the arrow button in the toolbar at the upper right, so that it's the first child page under the "Documentation" page.

If you take the time to make the content of the release notes more "xooki compliant" (by removing unnecessary end of lines and adding h2 h3 and h4 tags), the page could then look like something like that:
http://ant.apache.org/ivy/history/2.0.0-alpha-1.html

6. Commit your changes

svn status
svn add doc/ivy.xsd
svn add doc/release-notes.html
svn ci -m "update templates, add release notes and ivy.xsd in documentation."

7. Check that you have no pending modifications

svn status
If your working copy is clean, you can launch the release script. If it isn't, make sure to clean it properly. Sometimes you may need to call ant clean-all if you have started to work with ant builds. If you are confused about your working copy state, delete it and check it out again.

8. Launch the release script

ant -f build-release.xml release
The status should be release only for final releases, and milestone for any other intermediate release.
If anything is wrong, fix and go back to step 4.
If the release script is successful, release artifacts will be waiting for you in the build/distrib directory.

9. Verify the release

Check that all zips can be opened correctly, and that running 'ant' after unzipping the source distribution works properly.
You can also do a smoke test with the generated ivy.jar , to see if it is able to resolve properly a basic module (for instance you can run some tutorials provided in the src/example directory in all distributions).

10. Sign and upload the artifacts

It's now time to sign the release artifacts and upload them to a location accessible by other Apache commiters.

Here is a simple way to sign the files using gnupg: 
gpg --armor --output file.zip.asc --detach-sig file.zip
Here is a ruby script you can use to sign the files: 
require 'find'

Find.find('build/distrib') do |f| 
    `gpg --armor --output #{f}.asc --detach-sig #{f}` if File.file?(f) && ['.zip', '.gz', '.jar', '.pom'].include?(File.extname(f))
end
Be prepared to enter your passphrase several times if you use this script, gpg will ask for your passphrase for each file to sign.

When you're done upload the content of the distrib directory to a publicly accessible web site, your apache personal site being a good location for this. Make sure you include some kind of disclaimer somewhere to inform people the release is not approved yet.

You can for example add a HEADER.html like this: 
<h2>WARNING: files available here are NOT an Apache approved release yet.</h2>

11. Prepare the Eclipse update site

To be able to test the release within IvyDE, it can be deployed in the IvyDE update site. See that page to know how to process.

12. Tag the svn repository

As soon as you are happy with the artifacts to be released, it is time to tag the svn repo 
svn copy https://svn.apache.org/repos/asf/ant/ivy/core/branches/2.0.0-beta1 \
           https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.0.0-beta1 \
      -m "Tag release 2.0.0-beta1."
And don't forget to set the svn:external on doc/xooki to a fixed revision. Edit the svn:external property on the folder doc/xooki in the tag and set it to the revision of the commit of the tag. It should look like: 
xooki -r790212 https://svn.apache.org/repos/asf/ant/ivy/site/xooki/
And commit that modification.

Publish the release candidate

13. Call for a vote to approve the release

Cast a vote to approve the release on the dev@ant.apache.org mailing list.

Here is an example: 
Subject: [VOTE] Ivy ${version} Release

I have built a release candidate for Ivy ${version}

You can download it from this URL: ${url}

Do you vote for the release of these binaries?

[ ] Yes
[ ] No

Regards,

${me}, Ivy ${version} release manager

14. Publish the release

If the release is approved, it's now time to make it public. The apache dist is manage by svnpubsub, so releases should be committed into https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION

If the release candidate has been staged into the dev area, then just do: 
$ svn mv https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION https://dist.apache.org/repos/dist/release/ant/ivy/$VERSION
If the candidate has been published on people.apache.org, just directly commit the artifacts into the subversion repository https://dist.apache.org/repos/dist/release/ant/

In order to keep the main dist area of a reasonable size, old releases should be removed. They will disapear from the main dist but will still be available via the archive. To do so, just use the svn rm command against the artifacts or folders to remove.

15. Update the web site

Add a link to the released version documentation in the web site.

To do so, you need to:
  1. add a svn externals reference to the documentation
    2. edit the svn properties of site/history, and in the svn:externals property, add a line like this one: 
    2.0.0-beta1 https://svn.apache.org/repos/asf/ant/ivy/core/branches/2.0.0-beta1/doc
    You should also change the latest-milestone external link.

    You can use "svn propedit svn:externals path/to/history" to do so.

    Once you've changed the property, use "svn up" to checkout the proper documentation.
  2. edit the toc.json file in the site component of Ivy
    3. and add something like that: 
    {
       "title":"2.0.0-beta1",
       "url":"http://ant.apache.org/ivy/history/2.0.0-beta1/index.html"
    }
    You can also edit the title of the main documentation node pointing to latest-milestone / latest-release if necessary.
Then you can update the release notes page of the imported documentation if necessary, to include the announcement for example.

It's time to update the download image used on the home page and the download page. Use site/images/ivy-dl.xcf as a basis if you have gimp installed. Then you can update the home page to refer to this image, and add a news item announcing the new version. Update also the download page with the new image and update the links to the download location (using a search/replace on the html source is recommended for this).

All site editing being done, commit your changes.

And now let's generate the site and deploy it:
  1. generate the part of the site for the new version:
    2. ant generate-history-ivy -Dhistory.version=2.0.0-beta1
    WARNING: that target is modifiying the toc.json in the imported branch so that the generated html have a proper version declared in the toc. You should not commit that change. Once the site has been generated, you may want to revert the changes so you won't commit it by mistake. (TODO: process to improve so we shouldn't worry).
  2. generate the website with the new toc:
    3. ant /all generate-site-ivy
  3. you should verify that the site generated in target is OK. And once your happy with it, commit the changes in target (some svn add might be needed !)
  4. deploy the website: go on people.apache.org and svn up /www/ant.apache.org/ivy/

16. Deploy the Eclipse updatesite

If the Eclipse update site has already been prepared to include that new Ivy release, it is now needed to be deployed. Then follow the deployment instruction on that page.

17. Announce

Announce the release on the dev@ant.a.o, ivy-user@ant.a.o, user@ant.apache.org and announce@apache.org mailing lists.
You can also announce the release on popular web sites, like freshmeat.net (xavier is the owner of the Ivy project on freshmeat), javalobby.org, theserverside.com, dzone.com, ...

16. Update this doc

If you feel like anything is missing or misleading in this release doc, update it as soon as you encounter the problem.

17. Merge your modifications back to the trunk if necessary.

Modifications on the template files do not need to be merged, but if you had troubles during your release you may want to merge your fixes back to the trunk.

18. Prepare next release

Update the file version.properties with the version of the next release so that anyone building from the trunk will obtain jar with the correct version number.

Release the version in jira, and create a new unreleased version for the next planned version.