Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Step by step of how to perform a Release via Maven


This document is intended to be kept up to date by the DSpace Release Managers.  It details the steps necessary to perform snapshot and official releases of DSpace and supporting Modules.


  1. Write access to the DSpace GitHub repository hosted at (All Committers should already have this, obviously)
  2. Write access to the org.dspace groupId in the snapshot and staging repositories hosted at  If you don't already have this, you will need to:
    • Sign up for a Sonatype JIRA account. This account will also serve as your login to the Sonatype OSS system. (If you already have a Sonatype account, you can skip this step)
    • Ask a Committer with release privileges (e.g. a previous release manager) to request that your Sonatype account be given release privileges to the "org.dspace" GroupID. This request should be submitted via the Sonatype JIRA system in the Open Source Project Repository Hosting project.
    • Once Sonatype gives you the proper authorization, you should be able to login to the Sonatype OSS system using the same login/password you setup in Sonatype JIRA. You should also have access to publish new releases to the "org.dspace" GroupID.
    • The full details of signing up and getting access to Sonatype are also posted online here: Sonatype Maven Repository Usage Guide
  3. You mustgenerate and publish your own personal Code Signing Key (required by Sonatype). Here are two sites that give hints on how to do that:


  • Preface- Should contain a very basic overview of the Release. Make sure the Release number is updated here!
    • NOTE: For Subminor releases (bug-fix-only releases), you may want to leave all information about the previous major release, and just enhance the content to state that this was a bug-fix release, and list any new contributors, etc.
  • Installation - Obviously make sure the Installation Documentation is updated for this Release
  • Upgrading a DSpace Installation - Same for the Upgrade Documentation, make sure it's up to date
  • History- Make sure the online History for this latest Release is included. You should be able to just edit the page, copy the fancy code that generated the history for another release, and update the version numbers. For example, copy the previous release's History section and change the release numbers as follows:
    • You'll notice all the release History is generated via the jiraissue plugin. In the url argument for that plugin, you should find the DSpace version number embedded in the querystring like: "... AND+fixVersion+%3D+%221.7.0%22 ..." If you look closely, you'll see the 'fixVersion' is set to "1.7.0" in that search string. All you should need to do is update that version number!
    • Also make sure to update the title argument for that jiraissueplugin to list the proper version number information


      Obviously, this is just a brief reminder of important areas of Documentation which always require updates. There's surely other areas, like Configuration section, which will require some updates for your release.


The above command will ask you three basic questions. Here are sample answers for DSpace 3.0:

Code Block

"What is the release version for: XXX" 3.0
 "What is SCM release tag or label for: XXXX" dspace-3.0
 "What is the new development version for: XXXX" 3.1-SNAPSHOT


  1. Login to
  2. Click "Staging Repositories" in the left column, then select the checkbox next to the staged repository on the right. The contents of it will open up at the bottom of the page.
  3. With the staged repository still selected, click the "Close" button at the top.
  4. Download and test that the artifacts in staging are exactly as they should be once deployed to central.

    titleIf You Need to Revert Back before Releasing

    If anything is incorrect, select the staged repository and select "Drop". After the problem is resolved, you can re-deploy the artifacts to staging and verify them again. To re-deploy an already-tagged release:
    mvn release:perform -Dtag=dspace-x.y -Darguments="-Dgpg.keyname=YourKeyId -Dgpg.passphrase=YourKeyPassword"

  5. If everything looks good, select the repository and select "Release". The artifacts should be synced to Maven central ( within an hour.

    titleOnce Released, There is No "Undo" Option

    Once you select "Release", there is no way to "undo" the release. If any major issues are found, you'll have to increment the version number and perform a new bug-fix release.


  • Add the new contributors to the list: DSpaceContributors
  • Coordinate Announcements with DuraSpace Staff:
    • Announcement on,, twitter
    • Ensure that the Latest Releasepage on is updated.
      • Plus, ask admins to upload latest documentation in PDF/HTML format
    • Announce on all DSpace mailing lists
    • Link announcement on Home of DSpace Wiki, change any version numbers listed on that page.
  • Update Wiki pages, particularly these pages which refer to the Current and Next Releases:
  • Also, update the Documentation Wiki area! Specifically:
  • For major releases, create a new branch in GitHub for any upcoming bug-fix releases: ((warning)NOTE: BRANCH INSTRUCTIONS NEED UPDATE FOR GITHUB!)
    • E.g., after 1.8.0 release, we created a 1.8.x branch for the subsequent 1.8.1 and 1.8.2 releases
    • To automatically create a branch, you may be able to use the release:branch command (NOTE: untested, but it should work! once we test it out, this may be the best practice way of creating a branch).
    • To manually create a branch, run a command similar to:

      Code Block
      svn copy \
            -m "Creating a branch for 3.x bug-fix releases."
      • Then, go back to your Trunk checkout, and make sure to update its version numbers in the pom.xml files by running the following:

        Code Block
        mvn release:update-versions

        (Remember to enter in the next appropriate majorversion number. E.g. After releasing 3.0, Trunk should be updated to "4.0-SNAPSHOT", while the new 3_x branch should be at "3.1-SNAPSHOT")

        • NOTE: the update-versions command doesn't always work perfectly. You will want to try a complete rebuild of DSpace before committing anything, as it sometimes misses updating a few version numbers.
      • You'll also need to ensure that all version numbers and the <scm> section is appropriate in the pom.xml files of your new Branch. Remember, the <scm> configurations should point at the branch, rather than back at Trunk.
  • For major releases, make sure to create a new DuraSpace BambooProject to auto-build the new branch you created in GitHub.
    • Usually, it's easiest to just 'clone' the existing Trunk project, rather than starting from scratch.
    • You'll want to name it something similar to "18BRANCH" (for 1.8.x branch).
  • Updates to JIRA:
    • Move any uncompleted issues to the next DSpace version tag in JIRA.
    • Ask a JIRA Administrator to close out the release in JIRA (this will ensure no new issues can be added to that release).