Page History

...

• 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.

  Note
  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.

  
  

Ensure you

...

specify the "latest" release in GitHub

If you are performing multiple releases at once (e.g. backporting security or bug fixes), it is IMPORTANT to tag your releases chronologically.  For example, the backported fixes to 3.x should be tagged BEFORE 4.x which should be tagged BEFORE 5.x. The reason for this is that the timestamp of the tag determines the ORDERING of the releases in GitHub.  So, in order for the 5.x release to appear after the backported releases, it needs to be released LAST.  then you need to tell GitHub which one to label as the "latest" release.

This can be done within the GitHub Release Notes by either checking or unchecking the "Set as the latest release" option.  For more details see the GitHub docs on managing releasesThe last tagged release will become the "Latest Release" in GitHub.

Warning: optional profiles need to be specified at compile time

...