| |
| Release Instructions |
| -------------------- |
| |
| V0.1Draft |
| |
| |
| This document provides an outline of how to perform a release for the C or Java |
| XML-Security libraries. (Hosted at http://xml.apache.org/xml-security.) |
| |
| Document Authors : |
| Berin Lautenbach |
| |
| NOTE: Based on ReleaseInstructions.txt from the Ant CVS |
| |
| Announce Release Plan |
| --------------------- |
| |
| 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. |
| |
| 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. |
| |
| Create Branches in CVS |
| ---------------------- |
| |
| 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 XMLSECC_11_BRANCH (for C library branches) or |
| XMLSECJ_11_BRANCH (for Java library branches). |
| |
| Once the branch is setup, the version numbers in CVS are changed. On the |
| branch, the build.xml (Java) or configure.ac (C++) version becomes 1.1Beta1 |
| while the main branch is updated to 1.2alpha. |
| |
| Build the Archives |
| ------------------ |
| |
| Ensure your GPG/PGP key is in the keys.txt file in the CVS. |
| |
| Export the xml-security module to a clean directory : |
| |
| cvs export xml-security |
| |
| Label the branch XMLSECC_11_B1 or XMLSECJ_11_B1 |
| |
| ** TODO - Create make process to build distributions and add commands here ** |
| |
| ** Java guys - what are the instructions to build the archives? ** |
| |
| Sign the archives |
| ----------------- |
| |
| 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 |
| |
| 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. |
| |
| Also make sure you have sent the key that you use to a public |
| keyserver. |
| |
| Transfer to Apache Web Site |
| --------------------------- |
| |
| The beta distribution is now ready to go. Bundle it up into a tar.gz file |
| and scp to your apache account. |
| |
| ** Do we have a standard set of WHATSNEW/README files? The would be updated |
| here ** |
| |
| Once this is uploaded, unpack things, create the release directory, |
| something like v1.1Beta1, push the release and README files into this |
| directory. |
| |
| The files should go to /www/xml.apache.org/builds/xml-security/release |
| on daedalus. |
| |
| ** Is the above correct? ** |
| |
| Address the available release tags in BugZilla. Create a new tag 1.1Beta1 |
| and a 1.2alpha. Assign all existing 1.1alpha bugs to one of these release |
| labels. |
| |
| Test the distribtion |
| -------------------- |
| |
| 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) |
| |
| ** What tests should be done to validate archives? ** |
| |
| If it looks OK, announce it on security-dev. After a few days pass and |
| there are no major problems, a wider announcement is made (main xml |
| website, general@xml.apache.org, etc). |
| |
| ** Any other files/lists to update? ** |
| |
| Announce beta releases at freshmeat.net (Do we have an entry?) |
| |
| 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. |
| |
| Try to advertise the need for testing of the betas as much as possible. |
| This should eliminate the need to release minor patch versions. |
| |
| To monitor the number of downloads, look at the access_log |
| file under /usr/local/apache2/logs |
| |
| When the final beta is considered OK, propose a vote on ant-dev to |
| officially adopt the latest beta as the XML-Security-C/J 1.1 release. If it is |
| passed, (it usually does,) this would be labelled XMLSECC_11 or XMLSECJ_11 |
| and built in a similar fashion to the above process. |
| |
| 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: |
| |
| ** NOTE I am guessing at all directories here ** |
| |
| * create a directory for the old release in |
| /www/xml.apache.org/builds/xml-security/release on daedalus. |
| |
| * Move the release notes, .zip files and corresponding signatures |
| and md5 hashes of the old release from |
| /www/www.apache.org/dist/xml-security |
| to a matching directory structure in |
| /www/xml.apache.org/builds/xml-security/release. |
| |
| * remove the remaining files except for the KEYS file from |
| /www/www.apache.org/dist/xml-security. |
| |
| * upload the new release files to |
| /www/www.apache.org/dist/xml-security/[source|binary]. |
| |
| * Create proper -current symlinks in /www/www.apache.org/dist/xml-security/ |
| |
| Change the links in /xdocs/bindownload.xml and /xdocs/srcdownload.xml, |
| regenerate the HTML files, commit and update the site. |
| |
| As the mirrors may need some days to pick up the new release, you |
| may want to add a note to that effect to the pages and remove it a few |
| days later. |
| |
| Now and perhaps during previous betas any changes on the branch must |
| be merged back into the tree. |
| |
| 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. ** |
| |
| Apache mailing lists that should get the announcements: |
| announce@jakarta.apache.org, announce@xml.apache.org, |
| announce@apache.org and security-dev |
| |
| Announce release at freshmeat.net |
| ** Do we have an entry? ** |
| |
| You can now reacquaint yourself with your family and friends. |
| |