This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Page tree
Skip to end of metadata
Go to start of metadata

DRAFT Procedure for creating a release using M2

This is currently a discussion page, and is not (yet) policy

Background

See Maven documentation: [http://maven.apache.org/developers/release/releasing.html Releasing A Maven Project].

Please prepare the POM(s) for the release, quoting from the above page:

Check that your poms will not lose content when they are rewritten during the release process.

  • mvn release:prepare -DdryRun=true
  • Diff the original file pom.xml with the one called pom.xml.tag to see if the license or any other info has been removed. This has been known to happen if the starting <project> tag is not on a single line. The only things that should be different between these files are the <version> and <scm> elements. Any other changes, you must backport yourself to the original pom.xml file and commit before proceeding with the release.
  • Remember to do 'mvn release:clean ' before you start the real release process.

Procedure for creating a release using M2

This assumes that the Commons Proxy is about to vote on 1.0-RC3.

  • Tag "proxy-1.0-rc3" but with the version number set to "1.0". This is so the release does not have to be rebuilt later just to fix the version.
  • Check out the tag proxy-1.0-rc3 into a clean local working directory
  • Build the release artifacts - I think there's a couple of options here:
    • Run the following maven command:
      mvn site javadoc:jar source:jar assembly:assembly
      This will create all the artifacts - jars and src and binary distros, but then you need to create checksums and sign (James Carman: link to how to do this?)
    • Run the following maven command:
      mvn -Prc -DcreateChecksum=true site install
      This should create all the artifacts installed in your local m2 repository, signed and checksums (note it also creates checksums for signature files - I delete those)
  • Upload the artifacts to people.apache.org/~<userid>/proxy-1.0-rc3 (e.g.) and call a vote on dev@ (James Carman: isn't there a mvn command to do this?)
  • Make sure that your signing key has been [http://www.apache.org/dev/release-signing.html#keys-policy added] to the commons-wide KEYS file (http://svn.apache.org/repos/asf/commons/trunks-proper/KEYS) found in SVN.

  • The vote e-mail should include:
    • URL for artifacts
    • URL for SVN tag
    • URL for website
  • If the VOTE passes, then the RC tag can just be copied to the formal release tag, i.e. without the RC suffix. The RC tag should be kept.
  • If the VOTE fails, the failed RC tag can be deleted if required.

Releasing commons-parent pom

  • Call a vote with a link showing the changes since the last release - example [http://mail-archives.apache.org/mod_mbox/commons-dev/200801.mbox/%3c55afdc850801030530tb7f5a59x2ea1ac35b62ab635@mail.gmail.com%3e here]

  • If the vote passes, cut the release using the [http://maven.apache.org/plugins/maven-release-plugin/index.html maven-release-plugin]

    • command svn up (makes sure your svn copy is up-to-date)
    • command mvn -Prelease release:prepare
    • command mvn -Prelease release:perform
  • No labels