Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by KelvinGoodson: http://wiki.apache.org/ws/Tuscany/TuscanyJava/SDOJavaReleaseSteps ------------------------------------------------------------------------------ ## page was renamed from Tuscany/TuscanyJava/SDO Java Overview/ReleaseSteps = Releasing SDO Java = + Note, this is information captured from my own experiences of doing a release for the first time. + If any of what I say here is at odds with apache policies as stated elsewhere then clearly they + win (Please let me know of any cases). + Rough notes moved to /RoughNotes to aid cleaning this up + + '''This is still work in progress''' Many items need another level of depth of explanation == Links == @@ -14, +20 @@ A relevant version of the Tuscany parent pom and buildtools must have been released. - == Tasks that can be done Ahead of Time or while in wait mode for the sequenced tasks + == Tasks that can be done ahead of time or while in wait mode for the sequenced tasks == + + 1. understand the planned release cycles of your dependencies and have a target stable release version in mind for all such dependencies 1. Prepare for signing/authenticating distro files 1. identify/install s/w for public key infrastructure stuff and MD5 message digest generation 1. Create a PGP key for signing files @@ -25, +33 @@ 1. Establish authentication with people.apache.org by key 1. Prepare a downloads page section that can be added to the Tuscany downloads page 1. Ensure that there is inter-module understanding of how we plan to sequence releasing modules and requesting IPMC votes - 1. drop a note to your apache mentos ensuring that they know you are planning to make a release + 1. ensure that our apache mentors know Tuscany's plans with respect to releases == Basic Task Sequence as I recall it == + - This is a basic sequence of tasks. Clarification of details of tasks is given below + This is a basic sequence of tasks. Clarification of details of tasks will be given below 1. make the trunk reference the newly released parent pom and buildtools 1. optionally make a branch 1. stabilize code in branch (or trunk if development activity can be halted in trunk) - 1. check LICENSE and NOTICE files in project roots and in jar manifests + 1. check LICENSE and NOTICE files in project roots and in jar manifests + 1. run the rat tool against the source and check for exceptions + 1. once exceptions have been fixed, store the rat log and make a note of rat log exceptions which are there because they have to be + 1. repeat this as necessary during the release process if new files are included 1. update release notes, readmes, etc - 1. If working in a branch, ensure the Tuscany project's STATUS file is up to date, and then copy/update it into the root folders of any source distribution that will be made, and to the location where the pom that creates the binary distribution will expect to find the STATUS file for packaging (may be the same location as for source distro) -- be aware that while the release process is continuing, the project STATUS file might change. + 1. Ensure the Tuscany project's root level svn STATUS file is up to date, and then copy/update it into the root folders of any source distribution that will be made, and to the location where the pom that creates the binary distribution will expect to find the STATUS file for packaging (may be the same location as for source distro) + 1. be aware that while the release process is continuing, the project STATUS file might change. 1. ..... - 1. Create release candidates and ask for feedback , iterating until ready for a PPMC vote + 1. Create release candidates and ask for feedback, iterating until ready for a PPMC vote ... 1. Create local copies of source hierarchies, one per source distribution, using svn export <uri> <local-dir> 1. Make archives of your clean exports in order to be able to distribute source 1. Follow the instructions in BUILDING.txt in the root folders of the source distributions to produce the binary distribution - 1. If you have to do something different from those instructions to build the binary distro, then update BUILDING.txt in appropriate places in svn(and be aware thet your source distro archive is now out of date) + 1. If you have to do something different from those instructions to build the binary distro, then update BUILDING.txt in appropriate places in svn(and be aware thet your source distro archive is now out of date, so you'll need to iterate before going public) - 1. create your sample source distribution + 1. create your sample programs source distribution 1. this is hacky at the moment and could be improved 1. ...... fill this in - 1. At this point you will have needed to put in place distro signing capabilities and easy access to people.apache.org + 1. .... + 1. At this point you will need to have put in place distro signing capabilities (see "Ahead of Time" above) 1. Sign and create md5 checksums for each of the source and binary distribution archives 1. transfer the archives to a logical place under your public_html people.apache.org space and arrange suitably - 1. create a suitable readme for the root level of your release candidate folder, and ensure the readme names the release candidate number + 1. create a suitable readme for the root level of your release candidate folder, and ensure the readme names the release candidate version 1. advertise the release candidate on tuscany-dev and tuscany-user and ask for feedback - 1. fix issues and repeat the release candidate process + 1. fix issues and repeat the release candidate process 1. When ready for the PPMC to vote on your release candidate, create a tag from the branch (or trunk if no branch) 1. Note that a release must have a referenceable tag from which it was built and that this may not be the end to your updates, so you have the option of creating new tags if the PPMC vote throws up more issues, or updating a single tag, you may like to bear your choice in mind when naming the tag 1. Note also that svn will complain when you try to do an svn commit into a tag, which is a warning only, and during this phase of the release process, updates to a tag are justifiable @@ -58, +72 @@ 1. Update the tags version names of the distributable artifacts to non SNAPSHOT titles that match the release name 1. Update the tags version names of the dependencies to non SNAPSHOT versions, if not already done earlier in the release candidate process 1. Ideally update the tags version names of maven plugins to non SNAPSHOT versions if not already done earlier in the release candidate process (note that if the plugin behaviour changes after release, your tag or source distribution may not build in the same way as it did when you released if you rely on SNAPSHOT plugin versions) + 1. Rebuild and upload a new release and candidate to people.apache.org + 1. Deploy the projects artifacts to the maven repository + 1. By this time you want to have in place easy authentication to people.apache.org (add link to apache description of how to do this), and to modify your maven ~/.m2/settings.xml file to use key based authentication, rather than password (I never got this going, so had to type in my password about 30 times per deploy) -- If using pageant to make an ephermeral decrypted version of your SSL private key available to the authentication process, then make sure pageant is running, and you have lodged your private key with that invocation of pageant + 1. Run maven deploy (supplying your password multiple times if necessary -- the build will fail if a password request times out) + 1. Check that the artifacts in the maven repository and the corresponding ones in your local repository are fresh and identical + 1. The deploy action will have created .md5 and .sha1 message digests for all newly deployed artifacts, you must manually add signatures for the artifacts + 1. for every archive artifact uploaded to the remote repository (see the "mvn deploy" execution log), create a signature for the corresponding artifact on your local machine + 1. upload that signature to sit alongside the artifact on the remote repository + 1. Request a vote on tuscany-dev on the new release candidate, and the deployed artifacts, publishing the rat log and exceptions stored earlier + 1. Iterate through the release candidate/vote process if necessary + 1. ask for ratification of the PPMC vote from the IPMC by posting to [email protected] (I think you may have to use an apache.org email address to do this?) + 1. if necessary repeat the release candidate/PPMC vote/IPMC ratification steps + 1. Move your release candidate files to the proper people.apache.org tuscany download location + 1. Add your ready prepared download section to the tuscany site downloads page, rebuild and deply the site update + 1. update the projects STATUS file and commit back to svn to say that the announcement has been made + 1. update the tuscany site's news page + 1. Announce the release by sending to [EMAIL PROTECTED] (note that you must use an apache.org email address to do this), copying tuscany-dev, tuscany-user and [EMAIL PROTECTED] + 1. Momentarily reflect on life's joys + + + + + ========================== + {{{ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
