Apache Maven 1.x has reached its end of life, and is no longer supported. For more information, see the announcement. Users are encouraged to migrate to the current version of Apache Maven.

Following Best Practices

At Maven, we eat our own dog food! Please make sure you are familiar with the Best Practices document and follow those techniques.

Releasing Maven or a Plugin

Prerequesites: you must define the following properties in ~/build.properties. (Note: you may want to put these in maven-plugins/plugin-parent/build.properties instead if you need to define them differently for other projects).

  • maven.repo.apache.releases.username - your apache username
  • maven.repo.apache.releases.privatekey - the filename of your SSH private key
  • maven.repo.apache.releases.passphrase - the passphrase for your private key ( not your Apache password)
  • maven.announcement.mail.from - Your name and email address, as subscribed to the users and developers mailing lists, e.g. Brett Porter <brett@apache.org>
  • maven.announcement.mail.server - The SMTP server to use for sending the announcement mail.

Release process

For more general notes on making a release, please see the Releasing documentation in the User's Guide.

  • Run maven scm:prepare-release and enter the appropriate tag ( MAVEN_[PROJECTNAME]_[MAJOR]_[MINOR]) and version.

  • Produce a clean build using maven -Dmaven.repo.list=apache.releases -Dmaven.site.deploy.live=true scm:perform-release. When prompted for the tag, enter the one used in the previous step. When prompted for the goal, enter plugin:repository-deploy,site:deploy for plugins, or jar:deploy,site:deploy for an individual JAR. To release a Maven distribution, see below.

  • Check for the new version at http://www.apache.org/dist/java-repository/maven/plugins/ or http://www.apache.org/dist/java-repository/maven/jars/.

  • Go to the JIRA administration page for the Maven subproject you have just released (Note that you need to be a JIRA administrator for this project) and release the version. Also make sure to add a new version for the following development version. This is required so that issue creators/developers can assign a "fix for" version to issues.

  • Run maven announcement. Edit this, then send it in a release email to the Maven user and developer lists. If you are happy with the default announcement, run maven announcement:mail.

Releasing a Maven Distribution

There are a couple of additional steps when releasing a Maven distribution.

  • Run maven maven:build-plugin-profile and check the versions are what you expect to distribute
  • Update the website files for the download links and release notes
  • Run scm:perform-release with the goals jar:deploy,maven:installer. Do this on Windows so that the .exe file is generated
  • Sign the distributions, and manually upload them to the distribution location (under /binaries/
  • Run scm:perform-release with the site:deploy goal, and mail out release notes

Some related FAQs

  • Q: When would I do a release?

    A: Plugins have their own release cycle now. So you can make a release whenever there is a change that you want to get into the hands of the users. This should be for major bugfixes and thoroughly tested and complete new features. You may also decide to make periodical releases every couple of months if there have only been minor bugfixes.

  • Q: What is the convention for versioning?

    A: Rewrites and changes that break compatibility are a major version number change. Announcements for these plugins should details what old functionality would be broken and link to a migration document on the plugin project web site. Minor version increments are for feature enhancements, major bugfixes and groups of bugfixes. These versions can go beyond 10: eg 1.13. A third version increment is optional and signifies minor updates. These may also be deployed as snapshots or users may just be asked to build out of CVS to acquire these fixes.

  • Q: Who decides when a plugin can be released?

    A: The lead developer of a plugin has the responsibility for making sure releases happen, but must first hold a vote on the Maven Developer list before cutting the release. The vote should detail the changes made and confirm that the testing has been performed and that there is no pending work that should hold up the release.