The following are the steps to follow when doing a release of the Scribble project:

<work in progress>

Update the ReleaseNotes.txt

Describe the changes associated with the release, in the ReleaseNotes.txt contained in the distribution modules. Make sure that it includes a URL for the release notes managed by the jira system.

Update the version in the source

The version number is defined in each pom.xml file, but when referenced in dependencies, is referred to using a property defined in the top level pom.xml (or tools/pom.xml for the tools build).

All of these locations need to be updated within the pom.xml files.

If dealing with a snapshot version (if moving from or to), then don't forget that within the pom.xml files, the format of the version is <major>.<minor>.<point>-SNAPSHOT. Whereas when dealing with non-snapshot releases, the format is <major>.<minor>.<point>.<tag>.

The value of the tag will dependent upon the nature of the release. The Scribble project uses the following conventions:

• <date>-M? - milestone, where ? represents a numerical value. The reason for the date prefix is to ensure that it is lexically in the correct order in respect of the other tags that come later in the cycle.

• CR? - candidate release, where ? represents a numerical value.

• Final - final release.

The other location where version information is defined is within the OSGi bundle and Eclipse plugin MANIFEST.MF files.

For the OSGi bundles, the MANIFEST.MF bundle version should be <major>.<minor>.<point>-SNAPSHOT or the release version as above.

For the Eclipse plugins, the MANIFEST.MF bundle version should be <major>.<minor>.<point>.qualifier or the release version as above. If the release version is not set, then maven/tycho will complain when building the release, that the qualifier based version does not match the version being used in the pom.xml.

Test the release

Download the distribution (both binary and source zips), and the update site zip, from the successfully completed hudson job triggered after the versions were updated.

Unpack the distribution and do the following checks:

1. Check the documentation has been included
2. Run the distributed examples as described in the examples guide

Upload the distribution, update site and documentation

Upload the distribution to http://downloads.jboss.org/scribble/releases/<version> and the update site to http://downloads.jboss.org/scribble/updates/<version> and set the <majorVersion>.x link to point to it.

Upload the documentation to http://docs.jboss.org/scribble/releases/<version>.

Once the artifacts are all uploaded, and correctly linked, then update the Scribble webpages (downloads and docs) to point to the relevant files.

Tag the release in Scribble's SVN repository

Create a tag for the new release. If the version is the first candidate release (e.g. CR1), then a branch should also be created for further work on this version. The trunk version should be updated to the next major or minor release number.

Publish the OSGi bundles to Nexus

From the 'bundles' folder, run 'mvn clean deploy' to upload the OSGi bundles (only) to Nexus.

Release the version in jira

Set the release date associated with the version in jira. This ensures that no further issues can be created against the version.

Reset the version in source

Set the version details back to SNAPSHOT in the source code. If the version released was first candidate, then this will need to be done in the trunk and the newly created branch.

See the instructions in the section above, on setting the version in the source, and perform the opposite task to return the versions back to their appropriate snapshot state (or .qualifier in the case of the plugins/features - currently designer's MANIFEST.MF and feature.xml).

Announce release on user forum

Final step is to announce the release on the User Forum.