Page History

...

...

For DSpace 7.x, you must use Java 11.

For DSpace 8.x, you must use Java 17.

Use Maven 3 or above

For more information see the Prerequisites section of the Sonatype Maven Repository Usage Guide

For DSpace 7.x or 8.x, you must use Maven 3.5.4 or above.  It's necessary to regenerate the LICENSES_THIRD_PARTY file (see notes below)

...

mvn {target} -Drelease

# NOTE: for DSpace 7.x and later, you MUST use the "-Drelease" flag in all commands.  It will automatically release all modules.

...

• 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.  
      • Find date of last major release (e.g. 6.0 was released on Oct, 24, 2016)
      • Use contributors graph to find contributors between 6.0 and 7.0, e.g. https://github.com/DSpace/DSpace/graphs/contributors?from=2016-10-24&to=2021-07-29&type=c
• Coordinate Announcements with LYRASIS Staff:
  
  • You might post draft announcements to a service such as https://gist.github.com/ 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 dspace.org website, twitter
  • (As necessary) Ensure that the Download page on dspace.org is updated.
    
    • Plus, ask dspace.org 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:
  
  • Current Release
  • Next Release Status
  • Releases
  • NOTE: See DSpace Wiki Style Guide for notes on how to actually edit the above Redirect pages
• 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 branch

After any minor release (e.g. 8.1 or 8.2), we need to merge the release tag back into the "main" branch for easier upgrades.  This allows ensures the "main" branch 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)

# 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

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 .

For more information on the "-s ours" merge command, see:

• Reset the common ancestor details from StackOverflow
• Recommended way to "supersede old development history of side branches" according to Git documentation.

Create Maintenance Branches (after major release)

...