This is a check list of stuff that has to be done before a new version of a plugin is released.
If the plugin is making its first official release, it should graduate from the sandbox. When this occurs, the following steps should be followed:
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:
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.
Before releasing for the first time you have to generate a GPG key and publish it. Information can also be found on Sonatype's How To Generate PGP Signatures With Maven.
|Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only)||1|
|What keysize do you want? (2048)||2048|
|Please specify how long the key should be valid. 0 = key does not expire n = key expires in n days nw = key expires in n weeks nm = key expires in n months ny = key expires in n years Key is valid for? (0)||0|
|Key does not expire at all Is this correct? (y/N)||y|
|Real name:||your real name|
|Email address:||your email address|
|Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?||O|
One part of a release is deploying the site documentation. Before being able to do so you have to import the Codehaus CA certificates into your JDK keystore. Follow the Codehaus instructions for Installing a new CA into the JDK.
For any deployment you have to make contact with one of the Codehaus servers, for which authentication is required. The best way to do this is to include the following sections in your personal settings.xml and fill in the xircles.username and xircles.password properties with your own credentials.
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <servers> <server> <id>codehaus.org</id> <!-- used for site deployment --> <username>jqhacker</username> <!-- xircles.username --> <password>SeCrEt</password> <!-- xircles.password --> </server> <server> <id>codehaus-nexus-staging</id> <!-- used for release deployment --> <username>jqhacker</username> <!-- xircles.username --> <password>SeCrEt</password> <!-- xircles.password --> </server> <server> <id>codehaus-nexus-snapshots</id> <!-- used for snapshot deployment --> <username>jqhacker</username> <!-- xircles.username --> <password>SeCrEt</password> <!-- xircles.password --> </server> </servers> <profiles> <profile> <id>verify-stage</id> <!-- convenience profile --> <repositories> <repository> <id>codehaus-nexus-staging</id> <url>https://nexus.codehaus.org/content/groups/staging/</url> <releases> <enabled>true</enabled> </releases> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>codehaus-nexus-staging</id> <url>https://nexus.codehaus.org/content/groups/staging/</url> <releases> <enabled>true</enabled> </releases> </pluginRepository> </pluginRepositories> </profile> </profiles> </settings>
(Note that using Maven password encryption is possible but may not work in combination with the xircles.password property, perhaps due to difficulties with brace expansion. Instead, duplicate your encrypted password into each of the server sections.)
The release process should be done using the Maven Release Plugin:
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>. You will also need to specify your password by adding -Dpassword=<Codehaus password>. (This is needed for the scm commits.)
This will build the plugin, javadocs and source. Everything will be deployed to the Nexus Repository Manager, ready to be staged. Be aware, that the site will be built and deployed as well. This means the site will up to date before the voting has even started. Trying to update the site afterwards seems to be much more complicated, this way we can assure the site will reflect the intended version.
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. You can use a template to be sure your email contains all the expected information.
When the vote has passed, do the following:
If the vote failed, the following steps have to be taken:
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:
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.
Manually update (without committing) one or two plugins on your local machine to use the new parent. Then run:
mvn clean verify site -Pmojo-release