Versions Compared


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


  • Make sure all contributors to the release have been added to the Release Notes!
    • Find the contributors: 
      • For bugfix releases

        Code Block
        # This example is to find the list of contributors to 6.3 
        # It lists contributors to 6.x branch since the 6.2 tag
        git shortlog -ns dspace-6_x ^dspace-6.2

      • For major releases (or from main branch), you can use GitHub contributors pages with a date range.  
  • Coordinate Announcements with LYRASIS Staff:
    • You might post draft announcements to a service such as and send out a call to committers for review.  When finalized, DSpace releases should be announced on the dspace-community, dspace-devel and dspace-tech lists/groups.
    • Announcement on website, twitter
    • (As necessary) Ensure that the Download page 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:
    • All Documentation page -> Has current release info
    • Add a warning to the documentation of the newest unsupported release (e.g. the warning for DSpace 1.7) and link to our Support Policy.
      Spaces - Space directory - (i) next to the space - Space Admin - Themes - Configure Theme - Header 
    • Homepage for the current Documentation (e.g. DSDOC7x) -> Has links to download latest version of DSpace
    • (If possible) Update the database schema diagram
  • Updates to GitHub: 
    • Move any uncompleted PRs to the next DSpace version tag / project board
    • Close any release-specific project board (after moving any uncompleted PRs or issues elsewhere)
    • Close the release milestone (adding date of the release)
  • Additional steps for Minor releases
    • See "Merge Minor Releases back to main branch" section below
  • Additional steps for Major releases
    • See also "Create Maintenance Branches" section below

Merge Minor Releases back to main & any later maintenance branch

After any minor release (e.g. 87.1 or 86.2, 7.6.3), we need to merge the release tag back into the "main" branch & later maintenance branches (e.g. dspace-8_x) for easier upgrades.  This allows ensures the "main" branch these branches is aware of any activity (commits) specific to that minor release.  It also allows sites to more easily upgrade to the next major release via "git merge [next-major-release-tag]"  (e.g. if currently running code from dspace-8.1  tag, you should be able to run get merge dspace-9.0  to upgrade to the next major release)

Code Block
# Start from current main
git checkout main

# Merge in the new minor release tag
# e.g. git merge -s ours dspace-7.6.2
git merge -s ours [minor-tag]

# Push updates to main
# If in doubt, create a PR first! 
# The result should be a PR with all the commits of the minor branch but zero code changes
git push upstream main

# If this is a 7.6.x bug fix, then ALSO update the 8.x maintenance branch
git checkout dspace-8_x
git merge -s ours [7.x-minor-tag]
git push upstream dspace-8_x

The resulting changes should be that zero code changes are made, but all the commit hashes from the minor release will be copied to main .