...

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 master/branch, run the following command:

...

The snapshot will be immediately available in the public Sonatype snapshot repository: https://oss.sonatype.org/content/repositories/releases/org/dspace/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

...

1. Create a new Release & Tag in GitHub.  See 

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

   help

   semver.

   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.0") off the current "main" branch.
   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.

   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
      yarn version ... info Current version: 7.4.0-next question New version: 7.4.0

      
      

2. 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.
3. 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.
4. 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

      
      

Create the PDF version of Wiki Documentation

...