Version 4

    We have commited ourselves to a release cycle of eight weeks per minor release in jbossws. To improve the predictability of releases we follow the following rules:

    The Release Cycle

    W2 Define set of JIRA issues
    W6 Work on issues
    W8 QA, Docs, Packaging

    At the end of W2 there are no more JIRA issues added to a release. Development continues in trunk until we reach code freeze at the end of W6. At the end of W6 there can be only release or documentation related unresolved issues. Then we branch and do the remaining QA related work in that branches. Finally we tag from the QA branches. We usually branch stacks and framework. Sometimes we also branch SPI, COMMON, FRAMEWORK or AS INTEGRATIONS, but only in case there are changes that require new release. The best way how to detect whether particular JBossWS module have to be released is to take a look to pom.xml of each JBossWS code base and check whether there is snapshot reference to SPI or COMMON.


    Make sure all tests against trunks are passing ( running on DEV QA Hudson ) before branching. It's also very useful to check TCK 5 before creating QA branches.


    The Release in JIRA

    Make sure we have a release issue in JIRA (i.e Release jbossws-3.x binaries and source)

    The release issue should have sub-tasks:

    The release jbossws native issue should have sub-tasks:

    Both release jbossws metro and release jbossws cxf issues should have sub-tasks:


    The Release in SVN

    At code freeze create a branch of the framework

    svn copy -m "Create QA branch"

    and the stack.

    svn copy -m "Create QA branch"

    Make sure there are no references to snapshot versions of thirdparty libraries in pom.xml

    After successful TCK testing, create tags for the TCK projects. This will allow us to reproduce the TCK runs.

    [tdiesler@tdvaio trunk]$ svn list
    JBoss_5_0_r67294_JBossWS_2_0_2_GA/The Release QA criteria

    Setup the Hudson Environment for the QA branch. Modify the periodic builds such that they do not conflict with the trunk QA if run on the same box.

    Assign somebody to run the TCK5.

    Make sure that every FIXME in the testsuite is still valid (see the Hudson console output). Issues that are resolved in JIRA should not have their associated test disabled in the testsuite.



    Run Maven-Repository-Clean hudson job regularly in release period to ensure our product is buildable from scratch because this job is run at Saturday night only.


    Doing the actual Release


    Use JDK 5 when building both binary and source distributions!

    1. Check webservices module on AS 5 trunk and propagate all changes made by other developers to our AS5 trunk integration layer if exists (see JBWS-2360 for example)
    2. Upload all required maven artifacts to the (i.e. CXF binaries/sources, native thirdpary dependencies)
    3. Verify release notes and install instructions
    4. Update the documentation dockbook: the docbook files can be automatically generated from the wiki using the magnolia2docbook utility in jbossws/projects area. The generated files needs to be copied into the stacks src/main/doc folder. Some changes might be required in the files that are not automatically generated (those having the index, introduction/shafholding pages, authors, etc.)
    5. Run the ant build-bin-dist target (binary distribution release)
    6. Install the release in JBossAS and make sure it builds, starts and all tests pass (on both Linux and windows platforms with no Internet access)
    7. Run the ant build-src-dist target (source distribution release)
    8. Install the release in JBossAS and make sure it builds, starts and all tests pass (on both Linux and windows platforms with no Internet access)
    9. When there are incompatible changes introduced with new release (such as introduced new jars or config files) then verify modified JBossAS starts with TCK configuration and update TCK code base accordingly
    10. Create SVN tags of JBossWS modules that require new release
    11. mvn deploy artifacts, finalize the release on Nexus repo
    12. Release the version in JIRA
    13. Update the jbossws front page at
    14. Update Supported_Target_Containers
    15. Publish the interop endpoints



    Announcing the Release

    1. Write a sticky post on the user forum
    2. Post a message to
    3. Post a message to
    4. Post a message to
    5. Go and have a beer