Update the release drafter workflow and configurations

[seisman]

This project uses the Release Drafter workflow to draft the next release notes (only visible to maintainers) from PRs.

• We're using the release-drafter/release-drafter@v5.8.0, but the latest version is v5.13.0. We should bump it to the latest version (we have set up the dependbot to bump the actions automatically, but the bot runs on every Tuesday, so we won't see it happen before v0.3.0 release). [Done in Bump release-drafter/release-drafter from v5.8.0 to v5.14.0 #889]

• Some new features were added since v5.8.0. One feature that may be useful to us is Allow adding the URL of the PR to the release notes release-drafter/release-drafter#582, which means we can write the full URL of PRs in the release notes, instead of running the sed command to replace #NUMBER to #NUMBER + URL.

• The release notes on GitHub are written in markdown, but the changelog are written in ReST. When we're going to make a release, we need to copy the draft release notes to changes.rst, convert it to ReST, create a PR and remove some items with low importance, merge the PR and then update the github release notes again. I found it very inconvenient because the two different markdown languages. I feel it would be much easier if we also use markdown for changelogs, i.e., changes.md instead of changes.rst.

• Changes are grouped into several categories: "Highlights", "New Features", "Enhancements", "Documentation", "Bug Fixes", "Maintenance", and "Deprecations". I don't like the current order of these categories. IMHO, these categories should be sorted by importance from the readers' point of view. Thus, the order should be

  1. "Highlights"
  2. "New Features"
  3. "Enhancements"
  4. "Deprecations"
  5. "Bug Fixes"
  6. "Documentation"
  7. "Maintenance"

[seisman]

As we are very close to making the v0.3.0 release, I think it may be better to work on this issue AFTER v0.3.0 release.

@willschlitzer will work on the final changelog/release notes of v0.3.0. After he finishes it and releases v0.3.0, we will have 4 contributors (@leouieda, @weiji14, @willschlitzer and @seisman) who have some experience with making PyGMT releases. Then we can better discuss if we want to make some changes to the release process.

[weiji14]

I've triggered dependabot manually at https://github.com/GenericMappingTools/pygmt/network/updates. Will merge the release drafter update PR at #889 after ensuring that @willschlitzer has a backup of the changelog as mentioned in #887 (comment).

[weiji14]

Note to find a better way to put links, or find the correct sed command:

Seems like the sed command missed a few, looks like we forgot to update it after #683 (comment). Try

sed -i.bak -E 's$\(#([0-9]*)\)$(`#\1 <https://github.com/GenericMappingTools/pygmt/pull/\1>`__)$g' changes.rst

Originally posted by @weiji14 in #887 (comment)

[seisman]

Note to find a better way to put links, or find the correct sed command:

Seems like the sed command missed a few, looks like we forgot to update it after #683 (comment). Try

sed -i.bak -E 's$\(#([0-9]*)\)$(`#\1 <https://github.com/GenericMappingTools/pygmt/pull/\1>`__)$g' changes.rst

Originally posted by @weiji14 in #887 (comment)

Updated command (convert #123 to ReST syntax):

sed -i.bak -E 's$#([0-9]*)$`#\1 <https://github.com/GenericMappingTools/pygmt/pull/\1>`__$g' changes.rst

Example input:

- Fix a bug (#50)
- Fix a bug (#52) another bug (#54)
- Fix two bugs (#123, #456, #789)

Output:

- Fix a bug (`#50 <https://github.com/GenericMappingTools/pygmt/pull/50>`__)
- Fix a bug (`#52 <https://github.com/GenericMappingTools/pygmt/pull/52>`__) another bug (`#54 <https://github.com/GenericMappingTools/pygmt/pull/54>`__)
- Fix two bugs (`#123 <https://github.com/GenericMappingTools/pygmt/pull/123>`__, `#456 <https://github.com/GenericMappingTools/pygmt/pull/456>`__, `#789 <https://github.com/GenericMappingTools/pygmt/pull/789>`__)

With this updated command, points 2 and 3 seem unnecessary.

[weiji14]

Just discovered MyST today and I believe it should address most of the ReST changelog pain points by switching things to markdown! It also opens up the possibility of converting some of *.rst files in doc from restructured text to markdown (much more new-contributor friendly) but that's for another discussion 😄

* [ ]  Some new features were added since v5.8.0. One feature that may be useful to us is [release-drafter/release-drafter#582](https://github.com/release-drafter/release-drafter/pull/582), which means we can write the full URL of PRs in the release notes, instead of running the `sed` command to replace `#NUMBER` to `#NUMBER + URL`.

See https://github.com/GenericMappingTools/pygmt/pull/941/files#r579724762. Need to set change-template: '* $TITLE [#$NUMBER]($URL)' in .github/release-drafter.yml file.

* [ ]  The release notes on GitHub are written in markdown, but the [changelog](https://github.com/GenericMappingTools/pygmt/blob/master/doc/changes.rst) are written in ReST. When we're going to make a release, we need to copy the draft release notes to `changes.rst`, convert it to ReST, create a PR and remove some items with low importance, merge the PR and then update the github release notes again. I found it very inconvenient because the two different markdown languages. I feel it would be much easier if we also use markdown for changelogs, i.e., `changes.md` instead of `changes.rst`.

Review the PR at #941, where changes.md is now used instead of changes.rst!

* [ ]  Changes are grouped into several categories: "Highlights", "New Features", "Enhancements", "Documentation", "Bug Fixes", "Maintenance",  and "Deprecations". I don't like the current order of these categories. IMHO, these categories should be sorted by importance from the readers' point of view. Thus, the order should be
  
  1. "Highlights"
  2. "New Features"
  3. "Enhancements"
  4. "Deprecations"
  5. "Bug Fixes"
  6. "Documentation"
  7. "Maintenance"

This order looks ok to me. Points 4, 5, 6 could be reordered differently perhaps but no strong opinions on this.