Changelog entry for v0.13.0

[seisman]

Description of proposed changes

This PR adds the changelog entry for v0.13.0.

• Release checklist: Release PyGMT v0.13.0 #3361
• Previous changelog PR: Changelog entry for v0.12.0 #3201
• Preview: https://pygmt-dev--3425.org.readthedocs.build/en/3425/changes.html

Checklist

• Add a new entry in doc/_static/version_switch.js for documentation switcher
• Add the version to the compatibility table doc/minversions.md
• Update citation information CITATION.cff and BibTeX at https://github.com/GenericMappingTools/pygmt#citing-pygmt
  • Update authorship list if necessary
  • Update DOI (and URL for BibTeX)
  • Update version
  • Update date released
  • Update the BibTeX key
• Copy the draft release note from https://github.com/GenericMappingTools/pygmt/releases to doc/changes.md
• Edit the changelog to look nice (see maintainers guide for details)
  • Update the release date and the DOI badge in doc/changes.md
  • Edit the list of people who contributed to the release, linking to their GitHub account. Sort their names by the number of commits made since the last release (e.g., use git shortlog HEAD...v0.1.2 -sne)
  • Edit the change list to remove any trivial changes (updates to the README, typo fixes, CI configuration, etc)
  • Update with any remaining PRs merged before release
  • Add highlights

[seisman]

Perhaps we should add a separate category for breaking changes?

[yvonnefroehlich]

Would make those changes more / directly visible to users!

Meaning we have to define a new label "breaking changes" and add it to

pygmt/.github/release-drafter.yml

Lines 8 to 20 in 6dc8eb0

	categories:
	- title: 'New Features'
	label: 'feature'
	- title: 'Enhancements'
	label: 'enhancement'
	- title: 'Deprecations'
	label: 'deprecation'
	- title: 'Bug Fixes'
	label: 'bug'
	- title: 'Documentation'
	label: 'documentation'
	- title: 'Maintenance'
	label: 'maintenance'

[weiji14]

Common changelog uses a prefix like **Breaking** or **<subsystem> (breaking):** for highlighting breaking changes, see https://github.com/vweevers/common-changelog?tab=readme-ov-file#244-prefixes. Maybe we could follow that instead of adding a new label/section?

[seisman]

Sounds good. Changes in 7d3ac63.

[weiji14]

Didn't want to bring this up so soon, but since Paul passed away, I'm wondering what the convention was in keeping his name on the citation list? Do we remove his name now, keep his name on for a couple more releases, or remove it after his funding/grants run out? See e.g. https://academia.stackexchange.com/questions/116845/dead-author-ethical-guidelines

[seisman]

Personally, I prefer to keep Paul's name at least in the period of the funding.

The link you provided only discussed the topic for journal articles, but here it's software and may be slightly different.

Anyway, we should keep this in mind and may need to revisit it later.

Edit: Probably should ask for comments from the GMT steering community. Will do it later.

[seisman]

This PR is ready for final review. I plan to merge this PR and make the release in 12 hours (before midnight for UTC+8 time zone).

[weiji14]

These should go under 'Deprecations' I think. We used to classify the NEP29 PRs as 'deprecations' (e.g. at https://www.pygmt.org/v0.12.0/changes.html#release-v0-11-0-2024-02-01), but somehow put the SPEC 0 PRs under 'maintenance' in Release v0.12.0. Probably should move them all to Deprecations.

[weiji14]

Looks good to me! Wait for second approval before merge.

[michaelgrund]

Looks good!

[yvonnefroehlich]

Looks good for me!