Conor's release instructions...

git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@272321 13f79535-47bb-0310-9956-ffa450edef68

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.
+