| 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.6. |
| Please interpret the branch names, tags, etc. according to |
| your context. |
| |
| 1. Propose a release plan for vote. This should set out the timetable for |
| the release under ideal circumstances. The level of bugs reported |
| can delay things. Generally, give a few weeks to "close" the source tree |
| to further changes so people can finalise contributions, etc. At this time, |
| the first beta will be cut and there will be then a period of beta testing, |
| usually 1 month but this should be flexible. |
| |
| 2. Note that any mention of a deadline causes a flood of bug fixes, new tasks, |
| etc. This needs to be managed as best it can. Some fixes will be applied, |
| others held over. Make this clear in the release plan. The committers and |
| particularly the release manager will need to make judgement calls here. |
| Anything too "big" is likely to be held over. |
| |
| 3. Once the freeze date arrives, create a branch for the release builds. You |
| will need to be comfortable in handling CVS branches with mutliple |
| merge-backs to the main branch and even selected merges from the the main |
| branch to the release branch. |
| |
| For more information on performing branching and merging, please visit |
| http://www.durak.org/cvswebsites/doc/cvs_54.php#SEC54 |
| |
| Label such branches ANT_16_BRANCH. |
| |
| 4. Once the branch is setup, the version numbers in CVS are changed. On the |
| branch, the version property in build.xml becomes 1.6Beta, |
| while the main branch is updated to 1.7alpha. |
| |
| [[ TODO: Check if the documentation files also need to be updated to point |
| to the right areas of Ant's website. ]] |
| |
| 5. Before a build : |
| |
| the first beta on the 1.6 branch should be called 1.6Beta1, ... |
| |
| the version property in build.xml governs the output of ant -version and |
| the naming of the distribution files. |
| |
| Update the following files for version number: |
| |
| On the branch only : |
| |
| * docs/manual/cover.html |
| * docs/manual/credits.html |
| * build.xml (version property & manifest-version property) |
| |
| Commit your changes. |
| |
| On the branch and on the main trunk (*): |
| |
| * xdocs/antnews.xml (Announcement) |
| * xdocs/faq.xml (Ant's history details - not for betas) |
| * xdocs/index.xml (Announcement, latest release details, link to |
| manual under "Documentation") |
| * xdocs/srcdownload.xml |
| * xdocs/bindownload.xml |
| |
| Generate the html files by invoking ant on docs.xml - you need |
| jakarta-site2 checked out for this. Commit the modified/generated |
| files |
| |
| 6. Ensure you have all the external libraries that Ant uses in your |
| lib/optional directory. To find out what libraries you need, execute |
| the build with -verbose option and scan for lines beginning with |
| "Unable to load...". |
| |
| 7. Next bootstrap, build and run the tests. Then build the distribution |
| on the branch. It is important that this be a clean build. Label this with |
| a tag ANT_16_B1. |
| |
| 8. Sign the distribution files using the following simple script |
| #!/bin/sh |
| for i in distribution/* |
| do |
| echo "Signing " $i |
| gpg -a -b --force-v3-sigs $i |
| done |
| |
| The --force-v3-sigs will improve the interoperability with PGP 5.x, |
| see <http://www.gnupg.org/(en)/documentation/faqs.html#q5.5>. |
| |
| Before you do that, ensure that the key you use is inside the KEYS |
| file in Ant's CVS repository - and that you perform a cvs update on |
| the KEYS file in /www/www.apache.org/dist/ant/ |
| |
| Also make sure you have sent the key that you use to a public |
| keyserver. |
| |
| 9. The beta distribution is now ready to go. Bundle it up into a tar.gz file |
| and scp to your apache account. |
| |
| 10. Meanwhile, 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. |
| Add instructions and warnings (GNU tar format issues, etc). |
| |
| You may choose to use the text2html convertor present at |
| http://www.aigeek.com/txt2html/ |
| |
| Name the generated file RELEASE-NOTES-x.y.z.html. |
| |
| [[ TODO: This must perhaps be an Ant task. ]] |
| |
| 11. Once this is uploaded, unpack things, create the release directory, |
| something like v1.6Beta1, push the release and RELEASE-NOTES files |
| into this directory. Create a symbolic link named README.html |
| that points to the RELEASE-NOTES. |
| |
| The files should go to /www/cvs.apache.org/dist/ant/ on minotaur. |
| |
| 12. Address the available release tags in BugZilla. Create a new tag 1.6Beta1 |
| and a 1.7Alpha. Assign all existing 1.6 alpha bugs to one of these release |
| labels. Note that such massive changes can be done at once by choosing the |
| link "Change several bugs at once" at the bottom of the bug list |
| displaying the 1.6alpha bugs. |
| |
| 13. Once that is done, do a test download to make sure everything is OK. A |
| common problem may be: |
| * the file's mime type is not recognized and is interpreted as |
| text/plain. Fix it by using some .htaccess magic (AddEncoding stuff) |
| * Your gz.asc files are not being displayed properly (RemoveEncoing stuff) |
| |
| If it looks OK, announce it on dev@ant and user@ant. After a few |
| days pass and there are no major problems, a wider announcement is |
| made (ant website, main jakarta website, announcements@jakarta.apache.org, |
| etc). |
| |
| and also perform a cvs update on files in minotaur's |
| /www/ant.apache.org/ |
| |
| Announce beta releases at freshmeat.net (Stefan Bodewig is the |
| owner of Ant's project entry - bug him ;-). |
| |
| 14. As problems in the beta are discovered, there may be a need for |
| one or more subsequent betas. The release manager makes this |
| call. Each time, the versions are updated and the above process is |
| repeated. Try not to have too many betas. |
| |
| 15. Try to advertise the need for testing of the betas as much as possible. |
| This would eliminate the need to release minor patch versions like |
| we had to do when releasing Ant 1.4. |
| |
| To monitor the number of downloads, look at the access_log |
| file under /usr/local/apache2/logs |
| |
| 16. When the final beta is considered OK, propose a vote on dev@ant to |
| officially adopt the latest beta as the Ant 1.6 release. If it is passed, |
| (it usually does,) this would be labelled ANT_16 and built in a similar |
| fashion to the above process. |
| |
| 17. BUT |
| |
| This time the directory you upload the files to is different and |
| you'll have to do some house-keeping for the old release: |
| |
| * upload the new release files to |
| /www/www.apache.org/dist/ant/[source|binary]. |
| |
| * remove the symbolic links from /www/www.apache.org/dist/ant. |
| |
| * Create proper -current symlinks in /www/www.apache.org/dist/ant/ |
| |
| * Make sure that the symbolic link README.html points to the new |
| RELEASE-NOTES. |
| |
| (**) |
| |
| 18. Update the ant.apache.org site : |
| |
| running cvs update *.html under /www/ant.apache.org should update the |
| files regenerated and committed in point 5 above (index.html, faq.html, |
| antnews.html, srcdownload.html, bindownload.html). |
| |
| Update the online manual too. |
| |
| 19. Clean up. |
| |
| * remove the remaining files of the previous release from |
| /www/www.apache.org/dist/ant/[source|binary]. |
| |
| * remove all *tar* files of the old release from |
| /www/archive.apache.org/dist/ant/[source|binary] on minotaur, |
| leave the *zip* files alone. |
| |
| 20. Now and perhaps during previous betas any changes on the branch must |
| be merged back into the tree. |
| |
| 21. At this point in time, the release is done and announcements are made. |
| PGP-sign your announcement posts. |
| |
| [[TODO: Identify the mailing lists where announcements are to be made. |
| Also identify the webpages to which the announcements must go. ]] |
| |
| Apache mailing lists that should get the announcements: |
| announcements@jakarta.apache.org, announcements@xml.apache.org, |
| announce@apache.org, dev@ant and user@ant. |
| |
| Announce release at freshmeat.net |
| (Stefan Bodewig is the owner of Ant's project entry - bug him ;-). |
| |
| Announce release in the usenet groups comp.lang.java.softwaretools |
| and comp.lang.java.announce. |
| |
| 22. You can now reacquaint yourself with your family and friends. |
| |
| (*) the xdocs need to be updated on both the branch and the HEAD revision |
| because traditionally the ant.apache.org web site reflects the HEAD |
| revision of the xdocs, but the users downloading a distribution will get |
| the xdocs and the generated html from the branch and will complain if there |
| are discrepancies in version numbers. |
| |
| (**) Mirrors : the srcdownload.html and bindownload.html each list a number of |
| mirrors. For ant 1.6.0 the mirrors picked up the new version in 8 hours |
| or less, the release having been done at midnight on Dec 18th, the |
| mirrors had it on Dec 19th at 8 am. The srcdownload/bindownload pages both |
| contain a note advising users to be patient immediately after the release. |