Page History

...

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 groupId in the snapshot and staging repositories hosted at oss.sonatype.org.  If you don't already have this, you will need to:
   
   1. 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)
   2. 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.
   3. 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.
   4. NOTE: The full details of signing up and getting access to Sonatype are also posted online here: Sonatype Maven Repository Usage Guide
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
   • How to Generate PGP Signatures with Maven (required for all Sonatype releases)
   • Make sure to publish your Key file to hkp://pgp.mit.edu, as this is the Key Server Sonatype uses for verification:
     
     • (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 and searching on your name

...

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

echo "test" | gpg --clearsign

...

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 dspace-7_x (or main) yarn version ... info Current version: 7.4.6.1-next question New version: 7.6.1 ... (EXAMPLE for 8.0) info Current version: 8.0.0-next question New version: 78.40.0

      
      

   3. Commit the change to package.json 

      Code Block
      git commit -a -m "Update version tag for release" git push upstream dspace-7_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.

      Code Block
      yarn version ... info Current version: 7.4.6.1 question New version: 7.6.2-next ... (EXAMPLE for 8.0) info Current version: 8.0.0 question New version: 78.51.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 dspace-7_x (or main)

      
      

Create the PDF version of Wiki Documentation

...