Differences between revisions 19 and 20
Revision 19 as of 2006-11-21 05:07:36
Size: 8456
Editor: lresende
Revision 20 as of 2009-09-20 22:47:28
Size: 8456
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

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

  1. draft asf guidlines: http://incubator.apache.org/guides/releasemanagement.html

  2. here's how axis2 do it: http://wiki.apache.org/ws/FrontPage/Axis2C/releases/steps

Task Dependencies

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

  1. understand the planned release cycles of your dependencies and have a target stable release version in mind for all such dependencies
  2. Prepare for signing/authenticating distro files
    1. identify/install s/w for public key infrastructure stuff and MD5 message digest generation
    2. Create a PGP key for signing files
    3. Lodge your PGP key with a keyserver
    4. Put your public key in the svn KEYS file
  3. Get set up for easy file transfer to people.apache.org
    1. Identify/Install clients for ssh, secure copying and secure ftping
    2. Establish authentication with people.apache.org by key
  4. Prepare a downloads page section that can be added to the Tuscany downloads page
  5. Ensure that there is inter-module understanding of how we plan to sequence releasing modules and requesting IPMC votes
  6. 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 will be given below

  1. make the trunk reference the newly released parent pom and buildtools
  2. optionally make a branch
  3. 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. run the rat tool against the source and check for exceptions
      2. 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
      3. repeat this as necessary during the release process if new files are included
    2. update release notes, readmes, etc
    3. 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.
    4. .....
  4. 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>

    2. Make archives of your clean exports in order to be able to distribute source
    3. 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, so you'll need to iterate before going public)
    4. Test your binary distro; take the outputs of your build process and use them as if you were a new user who had just downloaded them
    5. create your sample programs source distribution
      1. ...... fill this in
      2. ....
    6. 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
      2. transfer the archives to a logical place under your public_html people.apache.org space and arrange suitably
      3. create a suitable readme for the root level of your release candidate folder, and ensure the readme names the release candidate version
      4. advertise the release candidate on tuscany-dev and tuscany-user and ask for feedback
    7. fix issues and repeat the release candidate process
  5. 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
    2. 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
  6. Update the version elements of the poms to define the version of the parent pom and buildtools that should be used (CHECK where and when this should be done)
  7. Update the tags version names of the distributable artifacts to non SNAPSHOT titles that match the release name
  8. Update the tags version names of the dependencies to non SNAPSHOT versions, if not already done earlier in the release candidate process
  9. 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)
  10. Rebuild and upload a new release and candidate to people.apache.org
  11. Optionally take a snapshot archive of your local maven repository for future issue resolution
  12. 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
    2. Run maven deploy (supplying your password multiple times if necessary -- the build will fail if a password request times out)
    3. Check that the artifacts in the maven repository and the corresponding ones in your local repository are fresh and identical
    4. 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
      2. upload that signature to sit alongside the artifact on the remote repository
  13. Request a vote on tuscany-dev on the new release candidate, and the deployed artifacts, publishing the rat log and exceptions stored earlier
  14. Iterate through the release candidate/vote process if necessary
  15. ask for ratification of the PPMC vote from the IPMC by posting to general@incubator.apache.org (I think you may have to use an apache.org email address to do this?)

  16. if necessary repeat the release candidate/PPMC vote/IPMC ratification steps
  17. Move your release candidate files to the proper people.apache.org tuscany download location
    • - /www/people.apache.org/dist/incubator/tuscany/java
  18. Add your ready prepared download section to the tuscany site downloads page, rebuild and deply the site update
  19. update the projects STATUS file and commit back to svn to say that the announcement has been made
  20. update the tuscany site's news page
  21. Announce the release by sending to anounce@apache.org (note that you must use an apache.org email address to do this), copying tuscany-dev, tuscany-user and general@incubator

  22. Momentarily reflect on life's joys

Tuscany/TuscanyJava/SDOJavaReleaseSteps (last edited 2009-09-20 22:47:28 by localhost)