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 ------------------------------------------------------------------------------ Rough notes moved to /RoughNotes to aid cleaning this up + == Links == + + 1. draft asf guidlines: http://incubator.apache.org/guides/releasemanagement.html + 1. 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. 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 + 1. Lodge your PGP key with a keyserver + 1. Put your public key in the svn KEYS file + 1. Get set up for easy file transfer to people.apache.org + 1. Identify/Install clients for ssh, secure copying and secure ftping + 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 + + == Basic Task Sequence as I recall it == + This is a basic sequence of tasks. Clarification of details of tasks is 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. 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. ..... + 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. create your sample 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. 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. advertise the release candidate on tuscany-dev and tuscany-user and ask for feedback + 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 + 1. 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) + 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) + + + {{{ + svn copy https://svn.apache.org/repos/asf/incubator/tuscany/java/spec/sdo-api https://svn.apache.org/repos/asf/incubator/tuscany/branches/java/suitable-branch-name/sdo-api + svn copy https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo https://svn.apache.org/repos/asf/incubator/tuscany/branches/java/suitable-branch-name/sdo + }}} + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
