Page History

...

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.

   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)

      Code Block
      yarn version

      
      

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.0") 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")
   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.

Create the PDF version of Wiki Documentation

...