Maven can simplify several areas of the release process for software but it is not a substitute for planning. Think about the process before starting any release.
Firstly, you must decide what form your distribution will take. For example:
Once you have decided: it's time to set up maven.
If you plan to distribute your normal artifact as is then use the existing deployment goals. See Deploying to the Internal Repository for discussions about distributing raw artifacts. Public releases (of course) require deployment to a public repository. If your usual internal repository is private (and you want to use maven to upload the artifacts) then some changes to your project's properties may be needed for the release.
Distributions as binary and source archives are supported by the distribution plugin. For installers, currently, Maven only supports the NSIS installer on Windows. See the NSIS plugin for information. In both cases, some configuration will be necessary. You may have to add extra scripting to get the release just as you want it.
It may take a little effort to create and test release generation but it only needs to be done once. Maven will then be able to reliable generate all future releases in this format.
A key step towards making a release in Maven is to verify that your build is going to be reproducible (see Best Practices for more).
You should check the dependencies of the project you will be releasing. Ensure that all dependencies on snapshots or other non-final releases are resolved to proper releases. Then test that the software runs correct against them.
Releasing against a development dependency may lead to problems later. Not only may this cause future compatibility problems for your users but if you remain pointing to a development dependency that is later overwritten, attempting to rebuild your release may lead to at best a different result, at worst a failure to build.
If there is no release of the software, but you know the current development build to be stable, as a last resort you should internally release that library (using the current time as a version, or similar). At least then your software has a concrete dependency that should not be overwritten.
Future Maven release tools will help to identify the existence of such snapshots and help to resolve them, in particular where they are your own and you are simultaneously releasing a set of projects.
If you are using a source control system, the release should be cleanly built from a tag (so that the release codebase is clearly known). So, the SCM needs to be tagged before the release is cut. Maven can provide assistance with this.
Currently, the only automated release mechanism in Maven for cutting releases is provided by the SCM plugin. Please refer to the documentation on Making Releases from SCM.
The SCM plugin cuts a release in two steps:
As discussed previously, if you are using an SCM, you should utilise the SCM plugin to do this as this will ensure a build against a clean checkout.
Ideally you should also build in a known environment each time.
Pay attention to the version of Java used to compile the release: some bytecode produced by later versions
may be incompatible with earlier versions. Look out for warnings provided by Maven about this. Maven can
offer assistance: setting maven.compile.target of the
Java Plugin passes the
target JVM to the compiler.
Note (however) that some more subtle
compatibilty issues may be introduced by some modern compilers which can be fixed only by using an older
compiler.
With everything together and prepared, cutting the release is quite simple (whether the project uses SCM or not). If the plugin supports it, you can deploy the released artifact directly to the repository.
While Maven will currently create and deploy an MD5 checksum along with your distribution, this is only useful for verifying download integrity when the sum can be download from a trusted repository. In many environments (including where there is public distribution over the internet) it is therefore recommended that additional measures be put in place to allow the authenticity of the release to be verified.
It is therefore recommended that (in these cases), an OpenPGP compatible digital signature is also created. The original signatures and (most importantly) the public keys used to sign the releases should be held on a tightly secured central server. (Most users will need to download the public key but may not be able to verify it using the web of trust. It is therefore vital that they can download the key from a secure server.) The public key should also be made available through a public key server (for example, the MIT key server) and efforts made to link it strongly into the web of trust. It is of crucial importance that all private keys used to sign releases be kept secure.
Since Maven does not currently support automatically generating digital signatures, it is recommended that you sign your release using GPG (or some other OpenPGP compatible application).
As part of the deployment, you might want to republish your Maven generated web site with the new release information, download links and release notes.
Finally, after the release is out and checked, you will want to make announcements to tell the world about it. Here again, Maven can help. (If you are using a sophisticated distribution system with mirroring, you should wait until the mirrors have sync'd before making the annoucements.)
If you are maintaining a change record, you can use the Announcement plugin to generate a plain text announcement "release notes" style announcement and have it mailed to an announcement or other mailing list.
PDF Documentation