...

git clone git@github.com:DSpace/DSpace.git dspace-release
cd dspace-release
git checkout dspace-37_x
 
(or whatever the current maintenance branch might be named)

...

...

1. Login to http://oss.sonatype.org/
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.
   1. The staged repository should begin in the "Closed" state, which means some automated verifications on the POM structure etc. have already been run. If it is not yet closed, select it and click the "Close" button.

3. Ensure that the artifacts in staging are exactly as they should be once deployed to Maven Central.  Here's a few things to watch out for...

   1. Download one (or more) of the POMs, and make sure the <version> tag is correct (e.g. 6.0 and not a SNAPSHOT version or similar)

   2. Compare it against a past release in Maven Central (https://search.maven.org/search?q=org.dspace), making sure it has the same JARs or WARs, etc

   3. Check if the file sizes looks reasonable (0 Bytes is probably not reasonable ;-)). You can also compare those to previous releases.

   4. You can also verify the checksums of one or more of the JARs/WARs in Sonatype versus those that were installed into your .m2 directory. They should be the same.

      Info
      title If 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 -Dmirage2.on=true -Dtag=dspace-x.y -DconnectionUrl=scm:git:git@github.com:DSpace/DSpace.git -Darguments="-Dgpg.keyname=YourKeyId -Dgpg.passphrase=YourKeyPassword"

      
      

4. If everything looks good, select the repository and select "Release". The artifacts should be synced to Maven central (https://search.maven.org/search?q=org.dspace) within 2 hours.

   Warning
   title Once 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.

   
   

   1. Keep in mind however, that the release should become almost immediately available in the public Sonatype repository: https://oss.sonatype.org/content/repositories/releases/org/dspace/

...

Release the Frontend (UI) via a GitHub Release Tag

The previous actions will have checked out the release tag into the target directory under [dspace-src]/target/checkout/dspace/. Navigate to that directory and execute the creation of the distributions using the following command. This will create two zip, two bzip and two gzipped files in the target directory. One set of files is the "binary" release, and the other set is the source release.

# NOTE: for DSpace 5.x, the LNI module must be manually specified (-Pdspace-lni) to ensure it is also distributed
# Additionally, if releasing using Java 7, then you must include "-Dhttps.protocols=TLSv1.2" to avoid protocol_version errors in Maven.

localhost$ cd target/checkout/dspace/
localhost$ mvn package -Pdistributions -Dmirage2.on=true
 [INFO] Scanning for projects...
 [INFO]
 [INFO] ----------------------------------------------------------------------------
 [INFO] Building DSpace Assembly and Configuration 3.0
 [INFO] ----------------------------------------------------------------------------
 ....
 [INFO] --- maven-assembly-plugin:2.2.1:single (default) @ dspace ---
 [INFO] Reading assembly descriptor: src/main/assembly/release.xml
 [INFO] Reading assembly descriptor: src/main/assembly/src-release.xml
 [INFO] Building zip: [full-path-to-dspace-src]/dspace/target/dspace-3.0-release.zip
 [INFO] Building tar: [full-path-to-dspace-src]/dspace/target/dspace-3.0-release.tar.gz
 [INFO] Building tar: [full-path-to-dspace-src]/dspace/target/dspace-3.0-release.tar.bz2
 [INFO] Building zip: [full-path-to-dspace-src]/dspace/target/dspace-3.0-src-release.zip
 [INFO] Building tar: [full-path-to-dspace-src]/dspace/target/dspace-3.0-src-release.tar.gz
 [INFO] Building tar: [full-path-to-dspace-src]/dspace/target/dspace-3.0-src-release.tar.bz2
 [INFO] ------------------------------------------------------------------------
 [INFO] BUILD SUCCESS
 [INFO] ------------------------------------------------------------------------

Release the Frontend (UI) via a GitHub Release Tag

Before running the "yarn version" command, you will need to tell your local "yarn" to NOT create a git tag.  We'll tag this release ourselves:

# This only needs to be done once. You can check your settings via "yarn config list"
yarn config set version-git-tag false

First, increment the release in our package.json.  Node.js / NPM / Yarn requires that release tags all be valid semantic versioning (https://semver.org/).

...

So, our "dspace-angular" release numbering looks slightly different than the backend release numbering. It's MAJOR.MINOR.PATCH

1. Major releases: 8.0.0 (would be compatible with v8.0 of the backend)
2. Minor releases: 7.4.0 (would be compatible with v7.4 of the backend)
3. Patch releases: 7.4.1 (would be compatible with v7.4 of the backend, but with very minor patches/fixes to the frontend codebase)

Increment the version by running (NOTE: This will immediately apply a git commit to update the "version" in package.json).  In the below example, the current version is "7.4.0-next", and we've updated it to be "7.4.0" in preparation for the "dspace-7.4" tagged release.

git checkout main
yarn version
...
info Current version: 7.4.0-next
question New version: 7.4.0

Commit the change to package.json 

git commit -a -m "Update version tag for release"
git push upstream main

...

• Note: Alternatively, you can choose to tag the release from command-line (via git tag), but GitHub allows you to create a new tag when creating a new release.
• Just create a new tag (e.g. "dspace-7.4") off the current "main" branch.

...

You'll need to run the "version" command a second time to update package.json for our next release.  In the below example, the current version is "7.4.0" and we've updated the version to be "7.5.0-next" for the next release.

yarn version
...
info Current version: 7.4.0
question New version: 7.5.0-next

1. Before running the "yarn version" command, you will need to tell your local "yarn" to NOT create a git tag.  We'll tag this release ourselves:

   Code Block
   # This only needs to be done once. You can check your settings via "yarn config list" yarn config set version-git-tag false

   
   

2. First, increment the release in our package.json.  Node.js / NPM / Yarn requires that release tags all be valid semantic versioning (https://semver.org/).

   1. So, our "dspace-angular" release numbering looks slightly different than the backend release numbering. It's MAJOR.MINOR.PATCH

      1. Major releases: 8.0.0 (would be compatible with v8.0 of the backend)
      2. Minor releases: 7.4.0 (would be compatible with v7.4 of the backend)
      3. Patch releases: 7.4.1 (would be compatible with v7.4 of the backend, but with very minor patches/fixes to the frontend codebase)

   2. Increment the version by running (NOTE: This will immediately apply a git commit to update the "version" in package.json).  In the below example, the current version is "7.4.0-next", and we've updated it to be "7.4.0" in preparation for the "dspace-7.4" tagged release.

      Code Block
      git checkout main yarn version ... info Current version: 7.4.0-next question New version: 7.4.0

      
      

   3. Commit the change to package.json 

      Code Block
      git commit -a -m "Update version tag for release" git push upstream main

      
      

3. Create a new Release & Tag in GitHub.  See https://help.github.com/en/github/administering-a-repository/managing-releases-in-a-repository for full instructions
   • Note: Alternatively, you can choose to tag the release from command-line (via git tag), but GitHub allows you to create a new tag when creating a new release.
   • Just create a new tag (e.g. "dspace-7.4") off the current "main" branch.
4. Make sure the GitHub Release description links to the Release Notes  It should also link to the Backend's GitHub Release (and visa versa).  Look at past 7.x releases for examples.
5. After the release, update our package.json with the next planned version to represent that the "main" branch is now for developing the next release.  NOTE: for Node.js / Angular, the "-next" suffix is the same as the "-SNAPSHOT" suffix used for Maven on the backend.
   1. If the next release is planned to be a major release, set the version to "[major].0.0-next"  (e.g. "8.0.0-next")
   2. If the next release is planned to be a minor release, set the version to "7.[minor].0-next" (e.g. "7.5.0-next")

   3. You'll need to run the "version" command a second time to update package.json for our next release.  In the below example, the current version is "7.4.0" and we've updated the version to be "7.5.0-next" for the next release.

      Code Block
      yarn version ... info Current version: 7.4.0 question New version: 7.5.0-next

      
      

   4. Commit the change to package.json 

      Code Block
      git commit -a -m "Update version tag for development of next release" git push upstream main

      
      

Create the PDF version of Wiki Documentation

Export the latest Wiki-based Documentation as PDF.

Create a new GitHub release

• From the GitHub UI, visit: https://github.com/DSpace/DSpace/releases
• Find the newly tagged release & click on "Add Release Notes"
• Add in some basic release notes (refer to prior versions for some standard text).  Please be sure to provide the following information:
  • A link to the Wiki Release Notes (in the DSDOC area)
  • A link to the general documentation for this release (again in the DSDOC area)
• When you are satisfied, publish the new release!

Update demo.dspace.org

• For 6.x, see demo6.dspace.org Notes
• For 7.x, see Updating DSpace 7 Demo Sites

Build Docker Images for Tagged Releases

Images can be built & pushed from command-line to DockerHub.  Again, use the same tag name (e.g. "dspace-7.0") as above.

Tim & Kim currently have Push access.  Request it from one of them if you don't have it yet.

cd <DSPACE-SRC>
--checkout tag--
docker build -t dspace/dspace:<tag> .
docker push dspace/dspace:<tag>

cd <ANGULAR-SRC>
--checkout tag--
docker build -t dspace/dspace-angular:<tag> .
docker push dspace/dspace-angular:<tag>

After the Release is Finished

• 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)
• See also "Create Maintenance Branches" section below

Create Maintenance Branches (after major release)

After a new major release (e.g. 8.0), we need to create a maintenance branch for any bug-fix releases.  This allows the "main" branch to hold commits for the next major release, while bug fixes get applied to the maintenance branch.

• For example, after 8.0, you'd create a "dspace-8_x" maintenance branch, while the "main" branch would move to pre-9.0 development.

Creating a maintenance branch must be done for the backend and frontend separately.

• For the Backend (DSpace/DSpace), you can use Maven to quickly & easily create this maintenance branch
  

  • The easiest way to create a new branch is by using the release:branch command.  This command uses the same params as "release:prepare" (see above examples), but will create a new branch  instead of a new tag.  For example:

    Code Block

    # Start from current main (latest code) git checkout main git pull upstream main # The examples below assume that "main" currently has a POM version of "[majorversion].1-SNAPSHOT" # DRY RUN: Create a branch named "dspace-7_x" from main # This will copy the existing POM version tags to the "dspace-7_x" branch. # It will ask you what the next version is, and update to that version in the "main" branch. mvn release:branch -DdryRun=true -Drelease -DbranchName=dspace-7_x # If everything looks good, run it for real. This will immediately create the branch in GitHub, # and then ask you again what new version to update the POMs on "main" to mvn release:branch -Dresume=false -Drelease -DbranchName=dspace-7_x # When selecting the next version for main, make sure it's a SNAPSHOT of the next major version (e.g. 8.0-SNAPSHOT)

    
    

  • Double check that the POM versions are now correct in both the "main" and maintenance branches.   If something is wrong, you should be able to use release:update-versions

    
    

    Code Block
    git checkout [branch-to-correct] mvn release:update-versions -Drelease

    
    

• For the Frontend (DSpace/dspace-angular), you will need to create the maintenance branch in a more manual fashion.
  • First, create the new branch using GitHub's UI.   Go to https://github.com/DSpace/dspace-angular/branches and click "New Branch". 
    • Give it the same name as the backend maintenance branch (e.g. "dspace-8_x")
    • Select "main" as the source branch

  • Now, check the "version" at the top of the package.json file in both branches.  Ensure the maintenance branch version looks like "[major-version].1.0-next".  Ensure the "main" branch looks like "[next-major-version].0.0-next".  If either one is incorrect, then fix it using "yarn version".  For example:

    Code Block
    git checkout main yarn version ... info Current version: 8.1.0-next question New version: 9.0.0-next

    
    

  • Then, commit your changes.

    Code Block
    git commit -a -m "Update version tag for development of next major release" git push upstream main

    
    

  • You likely should only need to update the version of one branch.  In the end, they should look like this:
    • "main" branch should have version="[next-major-version].0.0-next"  (e.g. 9.0.0-next)
    • maintenance branch should have version="[current-major-version].1.0-next" (e.g. 8.1.0-next)

Commit the change to package.json 

git commit -a -m "Update version tag for development of next release"
git push upstream main

Create the PDF version of Wiki Documentation

Export the latest Wiki-based Documentation as PDF.

Create a new GitHub release & upload distribution files

• From the GitHub UI, visit: https://github.com/DSpace/DSpace/releases
• Find the newly tagged release & click on "Add Release Notes"
• Add in some basic release notes (refer to prior versions for some standard text).  Please be sure to provide the following information:
  • A link to the Wiki Release Notes (in the DSDOC area)
  • A link to the general documentation for this release (again in the DSDOC area)
• Upload the distribution files and a PDF export of the documentation. There should be 7 total files attached:
  • dspace-[version]-release.tar.gz
  • dspace-[version]-release.tar.bz2
  • dspace-[version]-release.zip
  • dspace-[version]-src-release.tar.gz
  • dspace-[version]-src-release.tar.bz2
  • dspace-[version]-src-release.zip
  • DSpace-Manual.pdf
• When you are satisfied, publish the new release!

Update demo.dspace.org

• For 6.x, see demo.dspace.org Notes
• For 7.x, see Updating DSpace 7 Demo Sites

Build Docker Images for Tagged Releases

Images can be built & pushed from command-line to DockerHub.  Again, use the same tag name (e.g. "dspace-7.0") as above.

Tim & Kim currently have Push access.  Request it from one of them if you don't have it yet.

cd <DSPACE-SRC>
--checkout tag--
docker build -t dspace/dspace:<tag> .
docker push dspace/dspace:<tag>

cd <ANGULAR-SRC>
--checkout tag--
docker build -t dspace/dspace-angular:<tag> .
docker push dspace/dspace-angular:<tag>

After the Release is Finished

• Make sure all contributors to the release have been added to the Release Notes!
• 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, twitter
  • (As necessary) Ensure that the Latest Release 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. DSpace 6.x Documentation) -> Has links to download latest version of DSpace
  • Update the database schema diagram
For major releases, create a new branch in GitHub for any upcoming bug-fix releases:

• E.g., after the 3.0 release, we created a 3.x branch for any subsequent bug fix 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 commands similar to:

Code Block
language bash
git clone git@github.com:DSpace/DSpace.git branchit cd branchit git checkout -b dspace-3_x dspace-3.0 git push --set-upstream origin dspace-3_x

• Then, go back to your main checkout, and make sure to update its version numbers in the pom.xml files by running the following:

  Code Block
  git checkout main mvn release:update-versions

  (Remember to enter in the next appropriate major version number. E.g. After releasing 3.0, main 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.
• Push your verified changes back to GitHub.
• 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 master.
• Updates to GitHub: 
  • Move any uncompleted PRs to the next DSpace version tag / project board
  • Close the release milestone (adding date of the release)
• Find the contributors (helpful data for the announcement, you are drafting an announcement, right?): 

  • 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

Possible Errors you may Encounter

...