Release PyGMT v0.5.0

[willschlitzer]

Release: v0.5.0
Scheduled Date: 2021/10/29
Pull request due date: 2021/10/27

Priority PRs/issues to complete prior to release

• Add missing aliases to sphdistance #1516
• Add missing aliases to pygmt.grdgradient #1515
• Add missing aliases to pygmt.xyz2grd #1506
• Add missing aliases to grd2xyz #1537
• Add function to import seafloor crustal age dataset #1471
• Increase minimum thumbnail height in style.css to fit text #1575
• Allow non-string color when input data is a matrix or a file for plot and plot3d #1526
• Wrap grdvolume #1299
• Update region and projection standard docstrings #1510
• Support Python 3.10 #1591
• Wrap project #1122
• Wrap gmtselect #1429
• Allow GMTDataArrayAccessor to work on sliced datacubes #1581
• Add CITATION.cff file for PyGMT #1592

Before release:

• Run grep --include="*.py" -r 'remove_version="v0.5.0"' pygmt from the base of the repository to check if any deprecations and related tests should be removed in this version
• Reserve a DOI on Zenodo by clicking on "New Version"
• Finish up 'Changelog entry for v0.5.0' Pull Request:
  • Add a new entry in doc/_static/version_switch.js for documentation switcher
  • Update CITATION.cff and BibTeX at https://github.com/GenericMappingTools/pygmt#citing-pygmt
  • Add the documentation link https://github.com/GenericMappingTools/pygmt#documentation-for-other-versions
  • Add compatibility information https://github.com/GenericMappingTools/pygmt#compatibility-with-gmt-and-pythonnumpy-versions
  • Copy draft changelog from Release Drafter and edit it to look nice (see maintainers guide for details)

Release:

• At the PyGMT release page on GitHub:
  • Edit the draft release notes with the finalized changelog
  • Set the tag version and release title to v0.5.0
  • Make a release by clicking the 'Publish Release' button, this will automatically create a tag too
• Manually upload the pygmt-v0.5.0.zip and baseline-images.zip files to https://zenodo.org/deposit, ensure that it is filed under the correct reserved DOI

After release:

• Update conda-forge pygmt-feedstock [Usually done automatically by conda-forge's bot] pygmt v0.5.0 conda-forge/pygmt-feedstock#19
• Bump PyGMT version on https://github.com/GenericMappingTools/try-gmt (after conda-forge update) (Bump to PyGMT v0.5.0 try-gmt#31)
• Announce the release on:
  • GMT forum (do this announcement first! draft on https://hackmd.io/@pygmt. requires moderator status) done
  • [Major/Minor releases only] GMT website (News)
  • ResearchGate (after forum announcement)
  • Twitter (after forum announcement) https://twitter.com/gmt_dev/status/1454390118668718094

---

• Party 🎉 (don't tick before all other checkboxes are ticked!)

[willschlitzer]

@GenericMappingTools/pygmt-maintainers Please let me know if I have forgotten any priority pull requests.

[weiji14]

Due to an unforeseen family emergency, we'll need to push this release out by a week or two and assign a new release manager. Ideally we keep this to October still, so how about somewhere between 22-29 October? Any preferences @GenericMappingTools/pygmt-maintainers?

[willschlitzer]

Due to an unforeseen family emergency, we'll need to push this release out by a week or two and assign a new release manager. Ideally we keep this to October still, so how about somewhere between 22-29 October? Any preferences @GenericMappingTools/pygmt-maintainers?

My vote is October 27-29; I can stay the release manager if the delay is that long.

[willschlitzer]

I changed the release date to October 29th; if I should make it a week earlier please let me know!

[weiji14]

Ok, so we've got a reply from pyOpenSci (xref #677), and there's an impression that the disclaimer on our front README.md is a bit too scary:

🚨 This package is still undergoing rapid development. 🚨

All of the API (functions/classes/interfaces) is subject to change until we reach v1.0.0 as per the semantic versioning specification. There may be non-backward compatible changes as we experiment with new design ideas and implement new features. This is not a finished product, use with caution.

Maybe we should tone down on the wording of this disclaimer for PyGMT v0.5.0, as I suggested at pyOpenSci/software-submission#43 (comment). How do people feel about PyGMT's stability, especially considering that we have a deprecation policy in place at https://github.com/GenericMappingTools/pygmt/blob/v0.4.1/doc/maintenance.md#backwards-compatibility-and-deprecation-policy?

[willschlitzer]

Ok, so we've got a reply from pyOpenSci (xref #677), and there's an impression that the disclaimer on our front README.md is a bit too scary:

Maybe we should tone down on the wording of this disclaimer for PyGMT v0.5.0, as I suggested at pyOpenSci/software-review#43 (comment).

I think it's a good idea to reword or remove this; our deprecation policy is at odds with a statement making it seem like every release may introduce breaking changes. The fact that we have changelogs and release announcement that discuss changes is sufficient, in my opinion, to inform users if there is a change that may break some of their code.

How do people feel about PyGMT's stability, especially considering that we have a deprecation policy in place at https://github.com/GenericMappingTools/pygmt/blob/v0.4.1/doc/maintenance.md#backwards-compatibility-and-deprecation-policy?

I think PyGMT has been very stable; since I came to the project 11 months ago. I don't think there have been any user-facing changes that would break older code. If the goal is to get PyGMT to v1.0, as the pyOpenSci reply indicates should be the goal for a paper, then I think we first need to come to a decision on some potentially breaking changes (#1318, #593, and #356 come to mind).

[willschlitzer]

@weiji14 Do we have a DOI for this upcoming release?

[weiji14]

@weiji14 Do we have a DOI for this upcoming release?

Yep, just reserved it. DOI for PyGMT v0.5.0 will be 10.5281/zenodo.5607255.