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

---------------------------------
W1
W2 Define set of JIRA issues
----------------------------------
W3
W4
W5
W6 Work on issues
----------------------------------
W7
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.

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:

• Release jbossws cxf binary and sources
• Release jbossws metro binary and sources
• Release jbossws native binary and sources
• Make sure that every FIXME in the testsuite is still valid every hudson workspace now contains an up-to-date errata file, which is the concatenation of exclude file and FIXME output
• Ensure correct line ends in windows shell scripts (CRNL)

The release jbossws native issue should have sub-tasks:

• Pass TCK5
• Release spi, common and framework
• Backport to trunks all issues fixed in branches - tracking all fixed issues in QA branches merged to trunks

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

• Release spi, common and framework
• Pass TCK5
• Backport to trunks all issues fixed in branches - tracking all fixed issues in QA branches merged to trunks

The Release in SVN

At code freeze create a branch of the framework

svn copy -m "Create QA branch" https://svn.jboss.org/repos/jbossws/framework/trunk
   https://svn.jboss.org/repos/jbossws/framework/branches/jbossws-framework-2.0.2

and the stack.

svn copy -m "Create QA branch" https://svn.jboss.org/repos/jbossws/stack/native/trunk
   https://svn.jboss.org/repos/jbossws/framework/stack/native/branches/jbossws-native-2.0.2

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 https://svn.corp.jboss.com/repos/tck/tck5/tags
JBoss_5_0_r64626_JBossWS_2_0_1_GA/
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.

Doing the actual Release

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 repository.jboss.org (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 https://www.jboss.org/author/
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 jbossws-announce@lists.jboss.org
3. Post a message to thecore@jboss.org
4. Post a message to http://jbossws.blogspot.com/
5. Go and have a beer