Release Numbering Convention

As of 2012 (starting with DSpace 3.0), DSpace has moved to a new release numbering scheme/format. Release numbers will now only consist of two numbers.

Release Numbering Scheme: [major].[minor] (e.g. 3.0, 3.1, 3.2, 4.0)

• Major Releases: incrementing the first number ('major') will represent a new MAJOR release of DSpace. A major release may include any or all of the following: new features, system improvements, architectural changes, bug fixes. All major releases end in ".0", so "3.0", "4.0", and "5.0" would all represent major releases.
• Minor (Bug-Fix) Releases: incrementing the second number ('minor') will represent a new MINOR release of DSpace. A minor release will only include bug fixes to an existing major release. For example, "3.1" and "3.2" would represent two minor releases which only include bug fixes to the "3.0" major release..

For more information see DSpace Release Numbering Scheme

Prerequisites

Verify Release Privileges

To perform a release, you must have all of the following:

1. Write access to the DSpace GitHub repository hosted at https://github.com/DSpace/DSpace. (All Committers should already have this, obviously)
2. Write access to the "org.dspace" namespace/groupId in the snapshot and staging repositories hosted at oss.sonatype.org.  If you don't already have this, you will need to:
   
   1. Register to publish in the Central Portal. This account will also serve as your login to the Central Portal.
      1. NOTE: If you already have a Sonatype account, you can skip this step.  Older Sonatype Jira accounts were also automatically migrated to the Central Portal (https://central.sonatype.com/)
   2. Ask a Committer with release privileges (e.g. a previous release manager) to request that your new account be given release privileges to the "org.dspace" namespace/GroupID. This request should be emailed to Central Support and include the username(s) to be added. The request MUST come from an email account which already has publisher access to the "org.dspace" namespace.
      1. The list of accounts which already has publish access to "org.dspace" can be found at https://central.sonatype.com/publishing/namespaces (after you login → click the three dots and select "View Users")
   3. Once Sonatype gives you the proper authorization, you should have immediate access to publish new releases to the "org.dspace" GroupID.
3. You must generate and publish your own personal Code Signing Key (required by Sonatype). Here are two sites that give hints on how to do that:
   
   • See Sonatype instructions on creating a Code Signing Key.  Or, Fedora's instructions on Creating a Code Signing Key
   • Make sure to publish your Key file to a supported Key Server.  Currently, Sonatype supports three Key Servers (keyserver.ubuntu.com, keys.openpgp.org, pgp.mit.edu):
     
     • (e.g.) gpg --keyserver hkp://pgp.mit.edu --send-keys [yourKeyID]
       

       • [yourKeyId] can be found by running the following command and copying the alpha-numeric string after the "/" on the "pub" line 

         • gpg --list-keys
           

     • You can see if your key is already on that Key Server by visiting http://pgp.mit.edu (or one of the other two) and searching on your name

Update Maven settings.xml with Sonatype User Token

Generate your Sonatype Central Portal Token via the instructions at https://central.sonatype.org/publish/generate-portal-token/

DSpace's root pom.xml already has the correct staging and snapshot repositories configured.  In order to deploy, you will need to add your Sonatype "central" user token to your local ~/.m2/settings.xml file. For example:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                      http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <servers>
    <!-- User Token for Sonatype's Central Portal Maven repository -->
    <!-- To generate a User Token (random username & password), follow instructions at
         https://central.sonatype.org/publish/generate-portal-token/ -->
    <server>
      <id>central</id>
      <username>YourUserToken</username>
      <password>YourUserTokenPassword</password>
    </server>
  </servers>
</settings>

If you don't yet have a ~/.m2/settings.xml file, you should create one, and copy the full contents above (obviously make sure to put in your user token and password token.

Using SSH and GPG agents

During a release you have to type the passwords of your GPG and SSH keys very often. Every DSpace module produces several files, all have to be signed and transfered to Sonatype. GPG and SSH agents help you to avoid typing passwords again and again. To use an ssh-agent just start it, export the required environment variables and add your ssh-key. To use a gpg agent start it, export the required environment variables and add the following to your ~/.m2/settings.xml:

<settings>
...
  <profiles>
    <!-- Profile to configure GPG signing of releases-->
    <profile>
      <id>gpg</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <properties>
        <gpg.useagent>true</gpg.useagent>
        <!-- If you have gpg2 instead, you can tell Maven to use it instead of 'gpg' by uncommenting the following -->
        <!--<gpg.executable>gpg2</gpg.executable>-->
      </properties>
    </profile>
  </profiles>
...
</settings>

On each maven run it may ask you once about your password which is a big improvement.

Java Version

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

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

Use Maven 3 or above

For more information about publishing via Maven, see Sonatype's Maven Documentation.

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

Unset MAVEN_OPTS, if you use it

If you normally use a MAVEN_OPTS environment variable on the machine you're using to cut the release, be sure to unset it, with this command:

unset MAVEN_OPTS

It's highly unlikely the configuration in your MAVEN_OPTS will be useful for the release. It's highly likely to cause problems. Better to be safe.

Making a Snapshot Release (e.g. 'dspace-x.y-SNAPSHOT')

For a new module (or a major modification), sometimes it can be useful to release a SNAPSHOT version to Maven.  That way you can test this SNAPSHOT version in a local DSpace build (or in a Docker build) before  you do the official release.

One Step Process

From a clean, up-to-date copy of "main" branch, run the following command

# Run a deployment with "release" profile enabled
mvn clean deploy -Drelease

You will have to enter in your GPG passphrase (which you established when you created your Code Signing Key).

The snapshot will be immediately available in the public Sonatype snapshot repository: https://central.sonatype.com/repository/maven-snapshots/

(NOTE: it's not possible to list the contents of the Snapshot repository, but our DSpace Parent POM references it as a source... so anything released to the Snapshot repository can be immediately tested/used by the DSpace codebase.)

Releasing a Single Module/Project

• If you'd like to release a Snapshot Release of that module, follow the instructions at: Making a Snapshot Release (e.g. 'dspace-x.y-SNAPSHOT')
• If you'd like to tag & release a new version of that module, use the module instructions at: Release DSpace Language Packs (I18N) Modules (NOTE: These instructions obviously have some specific notes around how the Language Packs modules are versioned. You obviously don't need to follow those versioning notes. Individual modules may have their own version schemes)

Making an Official Release (e.g. 'dspace-x.y' or 'dspace-x.y-rc1')

The Day Before the Release / Final Preparation  

Double Check Contents of all README (and similar) files in GitHub

Make sure that the contents of all README, LICENSE, LICENSES_THIRD_PARTY, NOTICE files are up-to-date in GitHub. These files reside in [dspace-src]. If anything is out-of-date, make sure to update it and commit the proper changes before continuing.

Request any CVEs from GitHub (if security fixes are included)

If this release includes fixes to any draft security advisories, make sure to request CVEs from GitHub as early as you can.  As of 2022, GitHub's policies currently say they will respond within 3 working days.  Since the announcement of the release requires the CVEs, you'll want to make sure that you have the CVEs assigned as early as reasonably possible.

(Keep in mind requesting CVEs does NOT make the security advisories public.  They will not become public until you publish them.  We recommend not publishing the security advisories until the release is already completed and the announcement is about to go out.)

Regenerate the Backend's LICENSES_THIRD_PARTY file

The "LICENSES_THIRD_PARTY" file is now autogenerated via a Maven command (using the codehaus license-maven-plugin). Simply run the following from your local source directory to re-generate this file:

# Install latest version of all dependencies in local cache
# (Only necessary if you haven't run this recently)
mvn -U clean install

# Regenerate LICENSES_THIRD_PARTY file
mvn verify -Dthird.party.licenses=true

On completion, a new, updated version of the LICENSES_THIRD_PARTY file will be written to your source directory. Please double check this file or "git diff" it to see if the changes look reasonable. Here are some things to especially be on the lookout for:

• If any dependencies are listed with an "UNKNOWN" license, then that means that dependency failed to specify its OS License in their own Maven POM file. We will need to manually lookup the license for that project, and manually add it to our src/main/license/LICENSES_THIRD_PARTY.properties file which corrects all "UNKNOWN" licenses. Finally, rerun the command above to regenerate the new LICENSES_THIRD_PARTY based on this update.
• If any dependencies are listed under an INCOMPATIBLE License (GPL, AGPL, etc), then we need to take a closer look at that dependency.  It is possible that the dependency is dual-licensed and therefore may be listed multiple times in the generated LICENSES_THIRD_PARTY file. If so, that's fine. If not, we may need to remove that dependency prior to the release.
• If any Open Source Licenses are listed under multiple names (e.g. "BSD" vs. "BSD License" vs. "BSD licence"), then we may need to update our POM configurations for the codehaus license-maven-plugin to tell it to merge licenses of those names into one. Those configurations are in the Parent POM under the <licenseMerges> tag of this plugin: https://github.com/DSpace/DSpace/blob/main/pom.xml#L713

If the file was updated, commit it.

Update Frontend's Language Packs files

Before performing a release, you should automatically sync any new English translations in "en.json5" to the other language packs.  This will add useful "TODO" comments to the "*.json5" files to allow translators to know which keys are still untranslated.

This can be achieved via a single command:

npm run sync-i18n
# DSpace 7 or 8: "yarn run sync-i18n"

NOTE: This command will also update the format of any "*.json5" files to align with the standard format (including spaces between keys and comments above each key with the English text).  This means the result may look like a large number of changes for some files, but most of the changes may be minor formatting changes.

The updated files should be committed to the codebase.

Release DSpace Language Packs (I18N) Modules

Before performing an official release, you should see if the DSpace Language Packs (i18n modules) need an updated release.  The easiest way to check if they need to be released it by checking to see if any commits have occurred since the previous release (see below for links).  Please note that you can release these I18N Modules on the same day as the main DSpace release.  The DSpace parent pom.xml is now configured to also check Sonatype's Release Repository for any Maven artifacts (so you do NOT need to wait for the I18N modules to appear in Maven Central)

At the moment the i18n modules are maintained in two separate GitHub projects. There are currently two i18n modules you will need to release:

• dspace-api-lang   - Check if any new commits have occurred on 'dspace-api-lang' since the last release. (Also required for 7.x and above!)

For each module, perform the full release steps that follow. To save space, the steps are only listed for one of the modules (but don't forget to run it for both language packs):

1. Checkout the Language Pack Module:
   

   1. git clone git@github.com:DSpace/dspace-api-lang.git dspace-api-lang


   2. cd dspace-api-lang

   3. git checkout main 
      NOTE: always release language packs from the main branch -- we do not use a maintenance branch for language packs.

2. Do a Dry Run: mvn release:prepare -DdryRun=true
3. Tag and Increment Version: mvn release:prepare -Dresume=false
   
   • Make sure to assign a version number of the format: [major].[minor].[sequence-number] (e.g. 5.0.0, 5.0.1, etc for 5.0 releases of language packs)
   • NOTE: The release process should suggest the correct version number by default
4. Deploy Artifacts to Staging in Sonatype: mvn release:perform
5. Verify and Release Staged Artifacts in Sonatype (see instructions at link)

Once both Language Packs have been released, you can immediately perform the DSpace release. You do not need to wait for them to appear in Maven Central, as our DSpace parent pom.xml will find them in Sonatype's Release Repository immediately.

Double Check Language Packs' Version Ranges

Once the Language Packs are released, you will probably need to modify the DSpace root pom.xml (https://github.com/DSpace/DSpace/blob/master/pom.xml) to reference the new version of the Language Packs. This should be similar to the following:

It is possible to make this change immediately after the i18n modules have been released.  However, you may initially see errors in the automated build in GitHub until the i18n modules are available in the Maven Central Repository.  These errors obviously will be resolved as soon as the i18n modules are available in Maven Central.

In the main pom.xml, provide the proper version range for each language pack. In the below example, we are saying to use any language pack version which is at least version 9.0.0, but is less than version 10.0.0:

<!-- DSpace Localization Packages -->
<dependency>
   <groupId>org.dspace</groupId>
   <artifactId>dspace-api-lang</artifactId>
   <version>[9.0.0,10.0.0)</version>
</dependency>

Ensure Documentation is Updated Appropriately

Hopefully, you've already been talking with others about getting Documentation updated!

You should also double check that the following "main pages" are updated in the Documentation:

• Release Notes- Should contain a very basic overview of the Release. Make sure the Release number is updated here!
  
  • NOTE: For minor 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. This section just links to all the tickets/PRs closed under the release "milestone" in GitHub.

  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.

Warning: optional profiles need to be specified at compile time

Just including a little warning about this up front. The following optional modules need to be specified with every mvn command below. We will make an effort to keep this list up to date, but you should verify it before you cut a new release. Things change. Forgetting an optional module means you'll have to cut another release.

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.

Checkout Main or Branch to Release

Checkout a fresh copy of the to-be-released version either from a branch or main. For example:

git clone git@github.com:DSpace/DSpace.git dspace-release
cd dspace-release
git checkout main

Note: do not just re-use an old working copy of the DSpace Main branch, for obvious reasons, you don't want your own work in progress sneaking into the release. It's also important to use the SSH repository path as noted above (NOT the https URL), otherwise you will be prompted for your GitHub credentials during the release process. More than once. Save yourself some time, be sure to use the SSH path.

Note: if you are doing a maintenance release, you will need to check out the maintenance branch, and not the main branch. In this case, the example above would instead read:

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

Do a Dry Run

This step is not required, but performs a useful sanity check without committing any changes. From your clean, up-to-date copy of master/branch, run the following command (from [dspace-src]):

# For DSpace 7.x or above (the "-Drelease" flag is required as it selects all modules to release)
mvn release:prepare -DdryRun=true -Drelease

You will have to enter in your GPG passphrase (which you established when you created your Code Signing Key).

echo "test" | gpg --clearsign

Tag and Increment Version

This step will set the version declared in the project's pom.xml files, commit the changes to master/branch, tag the release, and finally, check in the master/branch change that increments the next development version (e.g. x.y-SNAPSHOT) in the pom.xml files. Run the following (from [dspace-src]):

# For DSpace 7.x or above (the "-Drelease" flag is required as it selects all modules to release)
mvn release:prepare -Dresume=false -Drelease

(Optionally, you may also include the parameters -Dusername=YourGitHubUsername -Dpassword=YourGitHubPassword at the end of the above command, though I've not found these to be necessary)

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

You will also have to enter in your GPG passphrase (which you established when you created your Code Signing Key).

What do successful tagging results look like?

Assuming everything worked right, you should see ALL the following changes in GitHub:

1. A newly tagged version of DSpace under: https://github.com/DSpace/DSpace/tags
   
   1. For example, if you are releasing "3.2" you should see a newly listed tag "dspace-3.2" in the list of tags above.
2. The primary "pom.xml" file in that newly tagged version should have a <version> tag that correspond to the newly released version.
   
   1. For example, if you are releasing "3.2", then the "dspace-3.2" tag's main "pom.xml" should have a <version>3.2</version> tag
3. The primary "pom.xml" file in the original branch ("master" or a ".x" branch) should now be updated to the next SNAPSHOT version
   
   1. For example, if you are releasing "3.2", then the original "dspace-3.x" branch's pom.xml file should now have a <version>3.3-SNAPSHOT</version> tag

4. The results from Maven look similar to this. (Don't worry about the "SKIPPED" messages, those are normal, as the actual release process just runs from the "DSpace Parent Project")

   [INFO] ------------------------------------------------------------------------
   [INFO] Reactor Summary:
   [INFO]
   [INFO] DSpace Parent Project ............................. SUCCESS [2.320s]
   [INFO] DSpace Services Framework :: API and Implementation  SKIPPED
   [INFO] DSpace Kernel :: API and Implementation ........... SKIPPED
   [INFO] DSpace Addon Modules .............................. SKIPPED
   [INFO] DSpace Kernel :: Additions and Local Customizations  SKIPPED
   [INFO] DSpace XML-UI (Manakin) ........................... SKIPPED
   [INFO] DSpace XML-UI (Manakin) :: Local Customizations ... SKIPPED
   [INFO] DSpace LNI ........................................ SKIPPED
   [INFO] DSpace LNI :: Local Customizations ................ SKIPPED
   [INFO] DSpace JSP-UI ..................................... SKIPPED
   [INFO] DSpace JSP-UI :: Local Customizations ............. SKIPPED
   [INFO] DSpace SWORD ...................................... SKIPPED
   [INFO] DSpace SWORD :: Local Customizations .............. SKIPPED
   [INFO] DSpace SWORD v2 ................................... SKIPPED
   [INFO] DSpace SWORD v2 :: Local Customizations ........... SKIPPED
   [INFO] DSpace SOLR :: Local Customizations ............... SKIPPED
   [INFO] DSpace OAI 2.0 .................................... SKIPPED
   [INFO] DSpace OAI 2.0 :: Local Customizations ............ SKIPPED
   [INFO] DSpace Assembly and Configuration ................. SKIPPED
   [INFO] ------------------------------------------------------------------------
   [INFO] BUILD SUCCESS
   [INFO] ------------------------------------------------------------------------

What to do if you get tagging Errors?

Deploy Artifacts to Staging in Sonatype

This step will sign, checksum, and push all release artifacts (including javadocs and sources) to the Sonatype Central Portal (https://central.sonatype.com/). Run the following (from [dspace-src]):

# For DSpace 7.x or above (the "-Drelease" flag is required and it selects all modules to release)
mvn release:perform -Drelease

You should be prompted by Maven to specify your GPG passphrase (which you established when you created your Code Signing Key). If you run into any issues, it's possible to specify your GPG key and passphrase as arguments to the above command (e.g. -Darguments="-Dgpg.keyname=YourKeyId -Dgpg.passphrase=YourKeyPassword")

Verify and Release Staged Artifacts in Sonatype

1. Login to https://central.sonatype.com/
2. Under your account icon, go to "View Deployments" (direct link: https://central.sonatype.com/publishing/deployments)
3. You should see any recently sent "deployments" listed on this page.  If it was successfully "validated" based on Sonatype's requirements, you'll see a "Validated" label next to it.

4. 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://central.sonatype.com/search?smo=true&namespace=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.

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

5. If everything looks good, click the "Publish" button. The artifacts should be synced to Maven central (https://search.maven.org/search?q=org.dspace).

   Once Released, There is No "Undo" Option

   Once you select "Publish", 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. After clicking "Publish", the artifact will move into the "Publishing" status.  It will stay in that state until it is finally published ("Published" status), usually in only about 10-20 minutes.  You can check on the status by clicking the "Refresh" button or reloading the page.
   2. Once in the "Published" state, the release should appear at: https://repo1.maven.org/maven2/org/dspace/ and in Maven Central (https://search.maven.org/search?q=org.dspace)

Release the Frontend (UI) via a GitHub Release Tag

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

   # For 7.x/8.x. This only needs to be done once. You can check your settings via "yarn config list"
   yarn config set version-git-tag false
   
   # For 9.x. This only needs to be done once. You can check your settings via "npm config list" 
   npm config set git-tag-version 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.

      Example for 9.x or later

      git checkout main
      npm version [new-version]
      # E.g. npm version 9.0.0

      Example for 7.x or 8.x

      git checkout dspace-8_x (or main)
      yarn version
      ...
      info Current version: 7.6.3-next
      question New version: 7.6.3
      ...
      (EXAMPLE for 8.0)
      info Current version: 8.0.0-next
      question New version: 8.0.0

   3. Commit the change to package.json 

      git commit -a -m "Update version tag for release"
      git push upstream dspace-8_x (or 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.

      Example for 9.x or later

      npm version [next-version]
      # E.g. npm version 9.1.0-next

      Example for 7.x or 8.x

      yarn version
      ...
      info Current version: 7.6.3 
      question New version: 7.6.4-next
      ...
      (EXAMPLE for 8.0)
      info Current version: 8.0.0
      question New version: 8.1.0-next

   4. Commit the change to package.json 

      git commit -a -m "Update version tag for development of next release"
      git push upstream dspace-8_x (or main)

Release the REST Contract via a GitHub Release Tag

Just for consistency, we should also "tag" a release of the REST Contract which matches the release of the frontend & backend.  This is just simply adding a new tag.

1. 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-9.0") off the current "main" branch.
2. 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 releases for examples.

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!

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!  See the last release notes for details on generating this list

  # This example is to find the list of contributors to the current branch 
  # *since* June 21, 2024 (i.e. the last release).  It excludes all merge commits. 
  git shortlog -s -n -e --no-merges --since 2024-06-21

• Coordinate Announcements with LYRASIS Staff:
  
  • Release Announcement: A release announcement is drafted based on the Release Notes by the Tech Lead & Program Coordinator. This announcement should be sent to dspace-community, dspace-devel and dspace-tech lists/groups.
  • Website: Update the website pages which mention the latest release, including:
    • https://dspace.org/download/
    • https://dspace.org/how-to-configure-dspace/ (Links on this page)
    • https://dspace.org/features/ (Release Notes link on this page)
• Update Wiki pages, particularly these pages which refer to latest release:
  
  • Home
  • 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 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 7.x Documentation) -> 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. 7.6.2, 7.6.3), we need to merge the release tag back into the "main" & later maintenance branches (e.g. dspace-8_x) for easier upgrades.  This allows ensures 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)

# 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

# And the 9.x maintenance branch
git checkout dspace-9_x
git merge -s ours [7.x-minor-tag]
git push upstream dspace-9_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 .

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.
• See also https://github.com/DSpace/DSpace/issues/9616

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:

    # 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-9_x" from main
    # This will copy the existing POM version tags to the "dspace-9_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-9_x
    
    # What is the new working copy version for "DSpace Parent Project"? 10.0-SNAPSHOT
    
    # 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-9_x
    
    # When selecting the next version for main, make sure it's a SNAPSHOT of the next major version (e.g. 10.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

    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-9_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".  The maintenance branch version should be correct , but you will need to update the "main" branch version.  For example:

    Example for 9.x or later

    git checkout main
    npm version [next-major-version]
    # E.g. npm version 10.0.0-next

    Example for 7.x or 8.x

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

  • Then, commit your changes.

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

  • In the end, they should look like this:
    • "main" branch should have version="[next-major-version].0.0-next"  (e.g. 10.0.0-next)
    • maintenance branch should have version="[current-major-version].1.0-next" (e.g. 9.1.0-next)
• For the REST Contract (DSpace/RestContract), you will need to create the maintenance branch manually as well
  
  • Create the new branch using GitHub's UI.   Go to https://github.com/DSpace/RestContract/branches and click "New Branch". 
    • Give it the same name as the backend maintenance branch (e.g. "dspace-9_x")
    • Select "main" as the source branch
  • That's it! Nice and easy.

Update demo.dspace.org (after a major release)

After a new Major release, we need to update demo.dspace.org to use that new major release.  (The sandbox.dspace.org will always point at "main", so no changes are necessary there)

To update demo.dspace.org, you need to point it at the new maintenance branch.  So, for example, after the 9.0 release, then demo.dspace.org should be pointed at the dspace-9_x maintenance branch.  This ensures it starts on 9.0, but will be updated as maintenance to 9.x occurs.

As of 2025, this is a two step process:

1. Tim will have to submit a Pull Request to the DSpaceDirect deployment repository which does two things:
   1. Updates demo.dspace.org to use the new maintanance branch (e.g. dspace-9_x )
   2. If necessary, copies all environment variable settings (for custom configs) from sandbox.dspace.org to demo.dspace.org.  This ensures that, temporarily, the two sites are essentially "equal".  However, obviously, over time sandbox.dspace.org will diverge since it is watching the "main" branch.
2. Update our own "reusable-docker-build.yml" script to force a redeployment of demo.dspace.org whenever that maintenance branch is updated.  That is controlled by the "DEPLOY_DEMO_BRANCH" environment variable here: https://github.com/DSpace/DSpace/blob/main/.github/workflows/reusable-docker-build.yml#L75   Simply update that environment variable to point at the new maintenance branch.

For more info on the demo/sandbox sites, see also Updating DSpace 7 Demo Sites

Possible Errors you may Encounter

"Could not find model file" error (with language packs)

If you encounter one of these errors when building/packaging DSpace:

FATAL ERROR: "Reason: Could not find the model file '../dspace-xmlui-lang'. for project unknown"

OR

FATAL ERROR: "Reason: Could not find the model file '../dspace-api-lang'. for project unknown"

This is a known bug in Maven. The problem is that you likely have a 'dspace-xmlui-lang' or 'dspace-api-lang' folder at the same level as your [dspace-source] parent folder. Essentially, Maven located them and tried to add them into the build process (which it shouldn't have). The fix is to completely delete the "dspace-xmlui-lang" and "dspace-api-lang" folders, and try to rebuild DSpace.