From bba7a96e33bc112a32dc3bfc20fa5705c374778d Mon Sep 17 00:00:00 2001 From: Magesh Umasankar Date: Tue, 9 Apr 2002 18:21:09 +0000 Subject: [PATCH] Conor's release instructions... git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@272321 13f79535-47bb-0310-9956-ffa450edef68 --- ReleaseInstructions | 106 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 ReleaseInstructions diff --git a/ReleaseInstructions b/ReleaseInstructions new file mode 100644 index 000000000..16277a96e --- /dev/null +++ b/ReleaseInstructions @@ -0,0 +1,106 @@ +Instructions for making a Release: + +Author: Conor MacNeill + +Note: This document was created in the context of releasing Ant 1.5. + 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. + + [[ TODO: More information on multiple merge-backs needed ]] + + Label such branches ANT_15_BRANCH. + +4. Once the branch is setup, the version numbers in CVS are changed. On the + branch, the build.xml version becomes 1.5Beta1 while the main branch is + updated to 1.6alpha. + + [[ TODO: Check if the documentation files also need to be updated to point + to the right areas of Ant's website. ]] + +5. 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...". + +6. 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_15_B1. + +7. Sign the distribution files using the following simple script + #!/bin/sh + for i in distribution/* + do + echo "Signing " $i + gpg -a -b $i + done + + Try to do this on Linux since the gpg signatures generated on Windows may + cause some PGP users problems verifying signatures even though they seem + OK. + +8. The beta distribution is now ready to go. Bundle it up into a tar.gz file and + scp to your apache account. + +9. Meanwhile, convert the WHATSNEW file 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). + + [[ TODO: Any tool to automatically convert from text to html? ]] + +10. Once this is uploaded, unpack things, create the release directory, + something like v1.5Beta1, push the release and README files into this + directory. + +11. Address the available release tags in BugZilla. Create a new tag 1.5Beta1 + and a 1.6alpha. Assign all existing 1.5 alpha bugs to one of these release + labels. + +12. Once that is done, do a test download to make sure everything is OK. If it + looks OK, announce it on ant-dev and ant-user. After a few days pass and + there are no major problems, a wider announcement is made (main jakarta + website, general and announce lists, etc). + +13. 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. + +14. 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. + + [[TODO: Document how to monitor the number of downloads ]] + +15. When the final beta is considered OK, propose a vote on ant-dev to + officially adopt the latest beta as the Ant 1.5 release. If it is passed, + (it usually does,) this would be labelled ANT_15 and built in a similar + fashion to the above process. + +16. Now and perhaps during previous betas any changes on the branch must + be merged back into the tree. + +17. At this point in time, the release is done and announcements are made. + + [[TODO: Identify the mailing lists where announcements are to be made. + Also identify the webpages to which the announcements must go. ]] + +18. You can now reacquaint yourself with your family and friends. +