ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Ws Wiki] Update of "Tuscany/TuscanyJava/SDOJavaReleaseSteps" by KelvinGoodson
Date Thu, 16 Nov 2006 13:02:27 GMT
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:

  Rough notes moved to /RoughNotes to aid cleaning this up
+ == Links ==
+  1. draft asf guidlines:
+  1. here's how axis2 do it:
+ == 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
+   1. Identify/Install clients for ssh, secure copying and secure ftping
+   1. Establish authentication with 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
+ == 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
+    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
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
+    svn copy
+ }}}

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message