Release PyGMT v0.14.1

[seisman]

Release: v0.14.1
Scheduled Date: 20YY/MM/DD
Pull request due date: 20YY/MM/DD
DOI: 10.5281/zenodo.XXXXXXX

PRs that should be backported

• Fix the bug of converting Python sequence of datetime-like objects #3760
• CI: Separate jobs for publishing to TestPyPI and PyPI #3742
• Fix an image in README.md (broken on PyPI) and rewrap to 88 characters #3740
• Update License year to 2025 #3737
• clib.conversion._to_numpy: Add tests for Python sequence of datetime-like objects (#3758) #3776

Priority PRs/issues to complete prior to release

• plot no longer accepts date/time data in pygmt 0.14 #3757
• clib.conversion._to_numpy: Add tests for Python sequence of datetime-like objects #3758
• Fix the bug of converting Python sequence of datetime-like objects #3760

Before release:

• Check SPEC 0 to see if we need to bump the minimum supported versions of GMT, Python and core package dependencies (NumPy, pandas, Xarray)
• Review the "PyGMT Team" page
• README looks good on TestPyPI. Visit TestPyPI, click the latest pre-release, and check the homepage.
• Check to ensure that:
  • Deprecated workarounds/codes/tests are removed. Run grep "# TODO" **/*.py to find all potential TODOs.
  • All tests pass in the "GMT Legacy Tests" workflow
  • All tests pass in the "GMT Dev Tests" workflow
  • All tests pass in the "Doctests" workflow
• Update warnings in pygmt/_show_versions.py as well as notes in Not working transparency regarding GMT-Ghostscript incompatibility
• Reserve a DOI on Zenodo by clicking on "New Version"
• Finish up the "Changelog entry for v0.x.x" Pull Request (Use the previous changelog PR as a reference)
• Run make codespell to check common misspellings. If there are any, either fix them or add them to ignore-words-list in pyproject.toml
• Draft the announcement on https://hackmd.io/@pygmt

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 vX.Y.Z
  • Make a release by clicking the 'Publish Release' button, this will automatically create a tag too
• Download pygmt-X.Y.Z.zip (rename to pygmt-vX.Y.Z.zip) and baseline-images.zip from the release page, and upload the two zip files to https://zenodo.org/deposit, ensure that they are filed under the correct reserved DOI

After release:

• Update conda-forge pygmt-feedstock [Done automatically by conda-forge's bot. Remember to pin GMT, Python and SPEC0 versions]
• Bump PyGMT version on https://github.com/GenericMappingTools/try-gmt (after conda-forge update)
• Announce the release on:
  • GMT forum (do this announcement first! Requires moderator status)
  • ResearchGate (after forum announcement; download the ZIP file of the new release from the release page and add it as research item via the code category, be sure to include the corresponding new Zenodo DOI)
• Update release checklist template with any additional bullet points that may have arisen during the release

---

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

[seisman]

#3758 (comment)

I guess we also need to release v0.14.1.

Yes, wish we hadn't merged some of those deprecation PRs yet 🙂 We could either revert those, or branch off of commit b1c984a to make a release perhaps? Maybe start a new issue for this.

We need a patch release to address bug #3757. Since there are already 20+ commits (especially #3738, #3739) since v0.14.0 (v0.14.0...refs/heads/main), we can't create the patch release from the main branch directly.

So, we have two options:

• Revert changes in clib.Session: Remove deprecated open_virtual_file method, use open_virtualfile instead (Deprecated since v0.11.0) #3738 and clib.Session: Remove deprecated virtualfile_from_data method, use virtualfile_in instead (Deprecated since v0.13.0) #3739 and then create the release from the main branch
• Create a new branch from v0.14.0 and cherry-pick necessary fixes (e.g., mainly clib.conversion._to_numpy: Add tests for Python sequence of datetime-like objects #3758, but aslo need CI: Separate jobs for publishing to TestPyPI and PyPI #3742) into the new branch

I'm inclined to option 2.

[seisman]

• ResearchGate (after forum announcement; download the ZIP file of the new release from the release page and add it as research item via the code category, be sure to include the corresponding new Zenodo DOI)

I'm wondering if we should stop uploading the ZIP file to ResearchGate. The reasons are:

1. Downloading and uploading take some time.
2. I don't have the numbers, but I expect that very few users will download the ZIP file.
3. ResearchGate is not a good platform to distribute source code packages.
4. We already have the DOI for the research item, and people can just visit Zenodo for the package if they need it.

[weiji14]

So, we have two options:

• Revert changes in clib.Session: Remove deprecated open_virtual_file method, use open_virtualfile instead (Deprecated since v0.11.0) #3738 and clib.Session: Remove deprecated virtualfile_from_data method, use virtualfile_in instead (Deprecated since v0.13.0) #3739 and then create the release from the main branch

• Create a new branch from v0.14.0 and cherry-pick necessary fixes (e.g., mainly clib.conversion._to_numpy: Add tests for Python sequence of datetime-like objects #3758, but aslo need CI: Separate jobs for publishing to TestPyPI and PyPI #3742) into the new branch

I'm inclined to option 2.

We discussed the backporting strategy (option 2) before in #945 (comment) and a few other places, and decided it was somewhat of a chore, but would be happy to trial this. There will be quite a few backport PRs we'll need to open, so should we use an automated action perhaps? I mentioned https://github.com/python/miss-islington in #424 (comment), but there are probably other better ones out there now.

I'm wondering if we should stop uploading the ZIP file to ResearchGate.

The ZIP file upload is more just to create a 'news' item on ResearchGate. Maybe we can decide to skip the announcement steps for patch releases to simplify the process? The patch release could just be announced as a comment under https://forum.generic-mapping-tools.org/t/pygmt-v0-14-0-released/5668 perhaps.

P.S. I've opened a milestone for v0.14.1 at https://github.com/GenericMappingTools/pygmt/milestone/23

[seisman]

So, we have two options:

• Revert changes in clib.Session: Remove deprecated open_virtual_file method, use open_virtualfile instead (Deprecated since v0.11.0) #3738 and clib.Session: Remove deprecated virtualfile_from_data method, use virtualfile_in instead (Deprecated since v0.13.0) #3739 and then create the release from the main branch
• Create a new branch from v0.14.0 and cherry-pick necessary fixes (e.g., mainly clib.conversion._to_numpy: Add tests for Python sequence of datetime-like objects #3758, but aslo need CI: Separate jobs for publishing to TestPyPI and PyPI #3742) into the new branch

I'm inclined to option 2.

We discussed the backporting strategy (option 2) before in #945 (comment) and a few other places, and decided it was somewhat of a chore, but would be happy to trial this. There will be quite a few backport PRs we'll need to open, so should we use an automated action perhaps? I mentioned https://github.com/python/miss-islington in #424 (comment), but there are probably other better ones out there now.

Considering that we rarely release patch releases (the last patch release is v0.6.1 whihc is more than 2.5 years ago), I feel we can just do backporting manually, instead of exploring how bots work.

Edit: When releasing GMT 6.0 or 6.1, we also took some time to set up a backport app, and we haven't used it for a very long time.

[seisman]

I think the next steps are:

• Create the v0.14.x branch off the v0.14.0 tag
• Backport necessary changes (see the top post) into this branch (via PRs)
• If everything works well, go through the checklist and create the v0.14.1 tag

[yvonnefroehlich]

So, we have two options:

• Revert changes in clib.Session: Remove deprecated open_virtual_file method, use open_virtualfile instead (Deprecated since v0.11.0) #3738 and clib.Session: Remove deprecated virtualfile_from_data method, use virtualfile_in instead (Deprecated since v0.13.0) #3739 and then create the release from the main branch
  *Create a new branch from v0.14.0 and cherry-pick necessary fixes (e.g., mainly clib.conversion._to_numpy: Add tests for Python sequence of datetime-like objects #3758, but aslo need CI: Separate jobs for publishing to TestPyPI and PyPI #3742) into the new branch

I have no experience here, and if people think option 2 is good I am fine with this.

---

I think the next steps are:

• Create the v0.14.x branch off the v0.14.0 tag
• Backport necessary changes (see the top post) into this branch (via PRs)

I think we also need to consider PR #3737, and I would also include the PRs #3745 and #3751.
What's about the formulation improvements for the hlines and vlines docs in https://github.com/GenericMappingTools/pygmt/pull/3755/files#diff-157251acb3879ebd83f31df05ed9b94e3b82a96fe3868a74189959aaa35695e4 and https://github.com/GenericMappingTools/pygmt/pull/3755/files#diff-c22d24476522d746d2046bb15114142657ce779eed51296fe6909a7477520598?

• If everything works well, go through the checklist and create the v0.14.1 tag

[seisman]

I've backported five commits into the v0.14.x branch (see the top post for linked PRs), and I think we're done with patching the v0.14.0 release. Of course, there are more fixes that can be backported, but they're just very minor issues.