UIMA project logo
Checklist: Release
Apache UIMA

Search the site

 Checklist: Release

  1. Do one-time setup required for releasing.
  2. Finish up any changes, close Jiras, assign Jiras to proper release(s).
  3. Update the READMEs and RELEASE-NOTES.
  4. Announce on the dev list that you're doing a release so others can get any changes in, and also know not to be committing to trunk while you're in the middle of doing the release.
  5. Make a new build directory for this release, and svn checkout the trunk (svn "export" instead of checkout fails at a later commit step by the release plugin). This is so you can preserve the build for later upload of selected artifacts to the distribution spot.

    If instead you are building from an existing checkout, do a svn update to be sure the workspace is up-to-date.

  6. Purge your local maven repository of artifacts being built by running in the top level directory you'll be building from:

    mvn dependency:purge-local-repository

    Note that this will immediately re-resolve the dependencies from the maven repositories you have configured.

    Note: this doesn't seem to work, as the purged items end up being needed by the recursive module build. So, instead, just go to the .m2 .../uima/ node and consider deleting that directory.

  7. Try a full build: mvn clean install -Papache-release
  8. If retrying a release candidate, delete the old rc-xxx in svn xxx/tags/
  9. If retrying a release candidate, close (and drop as appropriate) any previous repository.apache.org staging repo
  10. More details on next steps are here

      Release one or more artifacts into the Apache Nexus staging repository. You can do multiple release:prepare/perform steps, with subsequent steps depending on the previous artifacts in their "release" version.

    1. Do next steps in top release artifact (single module, or mult-module top project).

        Release one or more artifacts into the staging repo.

      1. Scan poms to be sure there are no unintentional -SNAPSHOTs
      2. .
      3. mvn release:prepare -DdryRun and diff the resulting poms to verify nothing unintentional is dropped or updated incorrectly
      4. For multi-module projects, where all the submodules have the same version, use:
        mvn release:prepare -DdryRun -DautoVersionSubmodules.
      5. mvn release:clean to restore projects
      6. mvn release:prepare [-DautoVersionSubmodules]. Try to accept the default suggestions for names; you might change the SVN tag to include a "-rc1" suffix indicating a release candidate number.
      7. mvn release:perform
    2. Repeat above steps for all things being released in one go (not already in an aggregate).
    3. login to https://repository.apache.org using your Apache LDAP credentials, find the staging artifact, and right click - "close" it after all things that are being included in this release are present.
  11. If necessary, run mvn release:prepare on the eclipse update site. This will create the svn tag, and create the needed artifacts in the target/eclipse-update-site. Or, you can create the tag yourself, and run mvn install -Papache-release. No need to run release:perform because no artifacts from this are going to Maven central distribution.
  12. Copy any artifacts (together with their signings) to the staging spot. This is typically in your people.apache.org/~[userid]/public_html directory. For releases which include eclipse-update-site packagings, this should include any modifications to the composite update site or subsites (see eclipse-update-site.

    Be sure to copy artifacts from the build-from tag spot, which should have a path like: ...[top level project]/target/checkout/target. Note this is not from [top level project]/target. Doing this will guarantee that you're posting the artifacts built from the tag (which could be different from the release:prepare build in /target if someone snuck in a svn commit at the right moment.)

  13. Send [VOTE] message to dev list. List the staging repository that testers will need to add to their settings.xml files, and the distribution SVN repo link.
  14. Post RESULT message
  15. Delete any artifacts from the staging repo that aren't supposed to go to Maven Central (if any). The uimaj build doesn't put the bin.zip or bin.tar artifacts on the staging repo, but other builds might need some cleanup.
  16. Promote the release(s) from the staging repositories
  17. Add the approved staged artifacts to the release/uima spot. Do an svn add on the bin (zip and tar) and source-release files and their sigs. Do not add files like POMs which have line-endings, if they have signatures; the files added should be "binary" style files. (The line endings (if you build on windows) will be changed upon upload to svn, which will result in bad signatures).
  18. update the UIMA website docs/d with any generated docs, in a manner to minimize SVN space use, if possible. This includes: PDFs, HTML versions of docbooks plus the index.html; all go on the website under the uima.apache.org/d/ (non-SVN source) directory. Update the index.html as needed for the version.
  19. Copy RELEASE_NOTES and issuesFixed from the .../target/checkout where the mvn release:perform was done from to the UIMA web site in doc/d/[project-version].
  20. Update the downloads page of the web site
  21. Update Jira version info to reflect the release status and date
  22. Cleanup the SVN tag for the release candidate, removing any -rcXX, to indicate the release.
  23. After release appears on maven central, post an appropriate announce letter
  24. Add a news item for the release
  25. Add release to next Board report
  26. Celebrate :-)