Release PyGMT v0.14.1 #3759

seisman · 2025-01-09T03:31:44Z

Release: v0.14.1
Scheduled Date: 2025/01/30
Pull request due date: 2025/01/26
DOI: 10.5281/zenodo.14742338

PRs that should be backported

Priority PRs/issues to complete prior to release

Before release:

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!)

The text was updated successfully, but these errors were encountered:

seisman · 2025-01-09T06:12:32Z

#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 · 2025-01-09T09:26:29Z

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:

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

weiji14 · 2025-01-09T18:31:43Z

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 · 2025-01-10T01:12:11Z

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 · 2025-01-14T03:25:36Z

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 · 2025-01-16T08:49:43Z

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 · 2025-01-17T10:57:46Z

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.

yvonnefroehlich · 2025-01-22T09:43:01Z

Do we need to consider issue #3771, or is this not relevant as it started to occur after the release of v0.14.0?

yvonnefroehlich · 2025-01-28T10:56:59Z

Thanks @seisman for pushing this path release forward!

Draft the announcement on https://hackmd.io/@pygmt

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.

Hm. Looking at the GMT forum there are stand-alone release announcements for the patch releases v0.3.1 and v0.4.1 but I could not find v0.6.1 at the moment (looking at Hackmd it seems it was somehow inclueded in v0.6.0). So how do we want to continue here?

yvonnefroehlich · 2025-01-28T12:38:32Z

Run make codespell to check common misspellings. If there are any, either fix them or add them to ignore-words-list in pyproject.toml

Just looked at this point. Despite we have ND listed in pyproject.toml in ignore-words-list:

pygmt/pyproject.toml

Lines 69 to 70 in a8365ee

    
           [tool.codespell] 
        
           ignore-words-list = "astroid,oints,reenable,tripel,trough,ND"

I get this output:

(pygmt_env_dev_650) Yvonne@A181941:/mnt/c/Users/Admin/C2/EigeneDokumente/Studium/Promotion/01_GitHub/github_pygmt/pygmt> codespell
./pyproject.toml:70: ND ==> AND, 2ND
./pygmt/enums.py:34: ND ==> AND, 2ND
./pygmt/datatypes/header.py:212: ND ==> AND, 2ND

However, if I change it to lower case, i.e. nd, there is not output.

yvonnefroehlich · 2025-01-29T12:46:29Z

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.

I think the main idea behind adding the releases to RG was / is to make new releases more visible across the community and I feel this works. I do not think that a lot people download the source code (from RG) directly, but they see that a new release came out. Probably it should be also possible to add the new release without the uploading of the source code, but I do not have a strong preference here.

BTW: Just saw that for v0.13.0 and lower versions, Jing-Hui's name is also mixed up on RG:

v0.13.0	v0.14.0

I tried to edit the author list but I am not able to do this and I can only edit the name of the first four authors and the last author. This looks a bit like a RG issue, not sure if the person who added the record can do more here.

seisman · 2025-02-01T15:01:38Z

Draft the announcement on https://hackmd.io/@pygmt

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.

Hm. Looking at the GMT forum there are stand-alone release announcements for the patch releases v0.3.1 and v0.4.1 but I could not find v0.6.1 at the moment (looking at Hackmd it seems it was somehow inclueded in v0.6.0). So how do we want to continue here?

I think it really depends on how many changes are in each patch release. Versions like v0.3.1 and v0.4.1 have many documentation changes and enhancements, so we made the release annoucement, but v0.6.1 mainly focused on fixing a few critical bugs, so no standalone annoucments were made.

As for v0.14.1, I agree that a comment under v0.14.0 annoucement is enough.

seisman · 2025-02-03T04:34:42Z

As for v0.14.1, I agree that a comment under v0.14.0 annoucement is enough.

Done at https://forum.generic-mapping-tools.org/t/pygmt-v0-14-0-released/5668/2.

seisman · 2025-02-03T04:47:58Z

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.

I prefer to skip v0.14.1 on ResearchGate. But if someone wants to add the v0.14.1 item on ResearchGate, feel free to do so.

seisman · 2025-02-04T04:38:26Z

Run make codespell to check common misspellings. If there are any, either fix them or add them to ignore-words-list in pyproject.toml

Just looked at this point. Despite we have ND listed in pyproject.toml in ignore-words-list:

pygmt/pyproject.toml

Lines 69 to 70 in a8365ee

[tool.codespell]
ignore-words-list = "astroid,oints,reenable,tripel,trough,ND"

I get this output:
(pygmt_env_dev_650) Yvonne@A181941:/mnt/c/Users/Admin/C2/EigeneDokumente/Studium/Promotion/01_GitHub/github_pygmt/pygmt> codespell
./pyproject.toml:70: ND ==> AND, 2ND
./pygmt/enums.py:34: ND ==> AND, 2ND
./pygmt/datatypes/header.py:212: ND ==> AND, 2ND
However, if I change it to lower case, i.e. nd, there is not output.

I can't reproduce it. Please make sure you have the latest codespell installed.

yvonnefroehlich · 2025-02-04T10:30:53Z

I can't reproduce it. Please make sure you have the latest codespell installed.

You are right, I missed the release on 2025/01/28 🙁. After updating, this issue disappeared, and codespell finds the typo reported in #3790 (which was not reported before).

seisman added the maintenance Boring but important stuff for the core devs label Jan 9, 2025

seisman pinned this issue Jan 9, 2025

weiji14 added this to the 0.14.1 milestone Jan 9, 2025

seisman mentioned this issue Jan 26, 2025

Changelog entry for v0.14.1 #3783

Merged

16 tasks

seisman closed this as completed Feb 3, 2025

seisman unpinned this issue Feb 3, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Release PyGMT v0.14.1 #3759

Release PyGMT v0.14.1 #3759

seisman commented Jan 9, 2025 •

edited

Loading

seisman commented Jan 9, 2025

seisman commented Jan 9, 2025

weiji14 commented Jan 9, 2025 •

edited

Loading

seisman commented Jan 10, 2025 •

edited

Loading

seisman commented Jan 14, 2025

yvonnefroehlich commented Jan 16, 2025 •

edited

Loading

seisman commented Jan 17, 2025

yvonnefroehlich commented Jan 22, 2025 •

edited

Loading

yvonnefroehlich commented Jan 28, 2025

yvonnefroehlich commented Jan 28, 2025

yvonnefroehlich commented Jan 29, 2025 •

edited

Loading

seisman commented Feb 1, 2025

seisman commented Feb 3, 2025

seisman commented Feb 3, 2025

seisman commented Feb 4, 2025

yvonnefroehlich commented Feb 4, 2025

Release PyGMT v0.14.1 #3759

Release PyGMT v0.14.1 #3759

Comments

seisman commented Jan 9, 2025 • edited Loading

seisman commented Jan 9, 2025

seisman commented Jan 9, 2025

weiji14 commented Jan 9, 2025 • edited Loading

seisman commented Jan 10, 2025 • edited Loading

seisman commented Jan 14, 2025

yvonnefroehlich commented Jan 16, 2025 • edited Loading

seisman commented Jan 17, 2025

yvonnefroehlich commented Jan 22, 2025 • edited Loading

yvonnefroehlich commented Jan 28, 2025

yvonnefroehlich commented Jan 28, 2025

yvonnefroehlich commented Jan 29, 2025 • edited Loading

seisman commented Feb 1, 2025

seisman commented Feb 3, 2025

seisman commented Feb 3, 2025

seisman commented Feb 4, 2025

yvonnefroehlich commented Feb 4, 2025

seisman commented Jan 9, 2025 •

edited

Loading

weiji14 commented Jan 9, 2025 •

edited

Loading

seisman commented Jan 10, 2025 •

edited

Loading

yvonnefroehlich commented Jan 16, 2025 •

edited

Loading

yvonnefroehlich commented Jan 22, 2025 •

edited

Loading

yvonnefroehlich commented Jan 29, 2025 •

edited

Loading