Preparing to Release

• Make sure the site documentation is up to date and follows the Development Guidelines .
• All open JIRA issues should be closed or agreed to be scheduled for a future version.
• Plugin must be documented and preferably have unit and integration tests.
• Update changes.xml to include all issues in JIRA that were fixed.
• If the release is a bugfix release (incrementing z): explicitly document the bugs fixed.
• If the release is a minor release (incrementing y): document the new features added. Make sure that these new features are properly documented, including:
  • Javadoc tags if the Mojo is written in Java
  • Examples
• Resolve all SNAPSHOTs if it's a proper release on all dependencies: Normal dependencies, build plugins, reporting plugins.
• Ensure the plugin complies with its intended minimum JRE requirement. For instance, if Java 1.4 is to be supported, actually set your JAVA_HOME to a JDK 1.4 and run mvn clean verify . This will catch references to classes or methods that were accidentally used but are only available in later versions of Java.
• Check that the POM properly declares its dependencies, i.e. run mvn dependency:analyze and fix any problems.

Graduating from the Sandbox

If the plugin is making its first official release, it should graduate from the sandbox. When this occurs, the following steps should be followed:

• Make sure the site follows the Development Guidelines .
• Call a vote for the graduation on the dev mailing list. See below for more info on how to do this.
• Move the svn project from sandbox/ to mojo/ .
• Change the POM parent from mojo-sandbox to mojo .
• Move the plugin site link on the plugin list from the section "Sandbox Plugins" to "Pre-release Plugins" by editing the plugins.apt document. Redeploy the site and verify that it is functional.

Preparing for the First Production Release

When a plugin is ready to have its first production release (i.e. not an alpha or beta release) there are a couple of extra things that needs to be taken care of:

• Create a separate JIRA project for the plugin. Every production plugin must have its own JIRA project. Pre-production plugins share the MOJO project in JIRA. If you don't know how to do this, or don't have the necessary karma, just ask for help on the dev mailing list.
• Make sure that the plugin's site passes the documentation checker plugin test. Run

  mvn docck:check
  

  If there are any errors - fix them. There are a couple of errors that might not need to be fixed. As an example: it's better not to add an FAQ document than to add a bogus one.

Call a Vote

Before a release can occur, a vote typically takes place. This is initiated with an email to the dev list, preferrably with a subject that starts with [vote] . Explain the plugin, status and any other info you feel relevant. The standard is to wait 72 hours for responses. This gives other developers time to verify the quality of the plugin before placing their vote. See the Apache Voting Guidelines for more information.

Performing the Release

The release process should be done using the Maven Release Plugin :

1. Execute mvn release:prepare

   This will make sure all code is checked in, tag the release and make sure the POM has no snapshot dependencies. If your local username is not the same as your codehaus username, be sure to add -Dusername= <codehaus username> .

2. Execute mvn release:perform

   This will build the plugin, javadocs and source. Everything will be deployed to the repository for synchronization to the central repository. The synchronization occurs every 4 hours. It will also build and deploy the site.

3. Verify that the central repository synchronization and the plugin site deployment occurred successfully.
4. Update the plugins.apt document to reflect the new release. Redeploy the mojo site and verify that it is functional.
5. Send out an annoucement email to dev@mojo.codehaus.org , user@mojo.codehaus.org and users@maven.apache.org .
6. TODO: if there's a feed containing all releases, get the release into that feed.

Releasing the Mojo Parent POM

Of course, to release the Mojo Parent POM, a vote takes place just for an ordinary plugin release. But when it comes to actually perform the release, there are some differences to watch out for:

1. Execute mvn release:prepare
2. Execute mvn release:perform -Dgoals=deploy

   The important thing to note here is the parameter -Dgoals=deploy . By default, the Release Plugin would execute the phases deploy and site-deploy on the parent POM. However, the site of the parent POM is not meant to be deployed, we have a separate project for this. The configuration of the site distribution in the parent POM exists solely for the purpose of inheritance by the plugins. Accidentally deploying the parent's site would damage the Mojo website, most notably the index.html .

3. Update the Development Guidelines to indicate the new POM version.