Closed seisman closed 1 month ago
It has been three months and more than 100 commits since PyGMT v0.12.0 (released on May 1st, 2024). Let us go with the PyGMT v0.13.0 release following our quarterly release plan. I expect to release PyGMT v0.13.0 in August and then v0.14.0 in December (pre-AGU or post-AGU).
Let us go with the PyGMT v0.13.0 release following our quarterly release plan. I expect to release PyGMT v0.13.0 in August [...]
Do you want to make the release already on the upcoming weekend π?
Let us go with the PyGMT v0.13.0 release following our quarterly release plan. I expect to release PyGMT v0.13.0 in August [...]
Do you want to make the release already on the upcoming weekend π?
I think not. The release date depends on the issues/PRs we want to address in v0.13.0. Personally, I want to refactor the data_kind
and virtualfile_in
functions in this release.
How about mid-Aug, say 14th or 15th? I'll be travelling for two weeks afterwards until early Sep so might not have so much time.
Personally, I want to refactor the
data_kind
andvirtualfile_in
functions in this release.
Agree that we should get some of that wrapped up. Unfortunately my laptop is crashing a lot recently (trying to get it fixed, might be a hardware issue), so I might be super slow on reviews until next week at least. Doing as much as I can on mobile in the meantime.
Let us go with the PyGMT v0.13.0 release following our quarterly release plan. I expect to release PyGMT v0.13.0 in August [...]
Do you want to make the release already on the upcoming weekend π?
I think not. The release date depends on the issues/PRs we want to address in v0.13.0. Personally, I want to refactor the
data_kind
andvirtualfile_in
functions in this release.
Ah, that's good π! For me, the upcoming weekend and starting of next week are already quite full. Maybe I can complete the tutorial for "draping a dataset on top of a topographic surface".
How about mid-Aug, say 14th or 15th?
Sounds good.
Personally, I want to refactor the
data_kind
andvirtualfile_in
functions in this release.
I just realized the virtualfile_in
method was added in v0.12.0 (#3068). Initially, I thought it was added after v0.12.0, then it makes sense to make breaking changes before making the v0.13.0 release. Since it was added in v0.12.0, there's no point in rushing to make breaking changes before 0.13.0 is released.
I'll focus on some smaller PRs before the scheduled release date.
Will submit a modified gallery example regarding #3320 during the week.
It seems @willschlitzer is no longer active in this project since one year ago (commits history at https://github.com/GenericMappingTools/pygmt/commits?author=willschlitzer). Perhaps we should move him to "Distinguished Contributors" on the "PyGMT team" page and also revoke some access permissions? It's also a good time for us to have an offboarding checklist, which is the reverse of our onboarding checklist.
@GenericMappingTools/pygmt-maintainers Please have a vote by π or π, or leave your comments.
Of course, @willschlitzer you're always welcome to come back at any time.
@GenericMappingTools/gmt-maintainers I'll be traveling from Aug 14 to Aug 18 and may have little time on this release. Maybe release it earlier, like Aug 12?
@GenericMappingTools/gmt-maintainers I'll be traveling from Aug 14 to Aug 18 and may have little time on this release. Maybe release it earlier, like Aug 12?
Hm. For me, I am not sure how much time I will have this weekend and I am afraid the beginning of next week will be quite full.
@GenericMappingTools/gmt-maintainers I'll be traveling from Aug 14 to Aug 18 and may have little time on this release. Maybe release it earlier, like Aug 12?
Hm. For me, I am not sure how much time I will have this weekend and I am afraid the beginning of next week will be quite full.
OK, we probably need to postpone this release to late August or early September, which is still good since we can have more time to improve the documentation.
OK, we probably need to postpone this release to late August or early September, which is still good since we can have more time to improve the documentation.
Fine with this. I'll be travelling soon for some workshops/meetings over the last two weeks of August, so could do early September. How about a release date on 5th September?
GMT 6.3.0 was released in Nov, 2021. As per our support policy
the PyGMT team has decided to discontinue support for GMT versions 3 years after their initial release.
So, we will likely drop the support of GMT 6.3.0 in either PyGMT v0.14.0 (planning to release in Q4 2024) or v0.15.0 (planning to release in Q1 2025). Following SPEC0, we will also drop Python 3.10 and pandas 1.x support. We should mention these future deprecations in the v0.13.0 release notes.
OK, we probably need to postpone this release to late August or early September, which is still good since we can have more time to improve the documentation.
Fine with this. I'll be travelling soon for some workshops/meetings over the last two weeks of August, so could do early September. How about a release date on 5th September?
I feel 5th September should be OK for me, as I think I will have less time to help with things up on the second week of September.
I guess it's time to finalize this release. @GenericMappingTools/pygmt-maintainers Do any of you volunteer to be the release manager?
Will submit a modified gallery example regarding #3320 during the week.
Hm. I feel we move this to v0.14.0? Or do you think @michaelgrund you can work on this tomorrow (today)?
I've reserved a DOI for this release 10.5281/zenodo.13679420
.
Will submit a modified gallery example regarding #3320 during the week.
Hm. I feel we move this to v0.14.0? Or do you think @michaelgrund you can work on this tomorrow (today)?
Yes, unfortunately I need to postpone these changes.
Changelog entry for this release is at https://github.com/GenericMappingTools/pygmt/pull/3425
Draft announcement for this release is at https://hackmd.io/V54IxrZGRv2eLr7z6n-7yQ
I guess it's time to finalize this release. @GenericMappingTools/pygmt-maintainers Do any of you volunteer to be the release manager?
I think I can help with reviewing the changelog PR and writing the release draft on HackMD later the day / in the evening.
I just made the v0.13.0 release and a discussion page (https://github.com/GenericMappingTools/pygmt/discussions/3426) is automatically created.
- GMT forum (do this announcement first! draft on https://hackmd.io/@pygmt. requires moderator status) https://hackmd.io/V54IxrZGRv2eLr7z6n-7yQ
The draft looks good to me except for two minor comments about the memorial session.
I just made the v0.13.0 release and a discussion page (https://github.com/GenericMappingTools/pygmt/discussions/3426) is automatically created.
Thanks for handling and making the release @seisman!
GMT forum (do this announcement first! draft on https://hackmd.io/@pygmt. requires moderator status) https://hackmd.io/V54IxrZGRv2eLr7z6n-7yQ
The draft looks good to me except for two minor comments about the memorial session.
I have addressed this two minor comments now. Maybe we leave this draft for some more time, and post it on Friday afternoon / evening on the forum?
The post looks good to me! Great work all!
Thanks @seisman for handling most of the release and @yvonnefroehlich for drafting the announcement post! (Sorry for my lack of activity, stil recovering from jetlag after 2 weeks of travel). Just skimmed through the post and it looks good ~I just have one suggestion which is to mention dropping support for GMT 6.3 (as mentioned above at https://github.com/GenericMappingTools/pygmt/issues/3361#issuecomment-2306842656). Assuming we want to do that in v0.14.0?~ Oh wait sorry, I see that it's already mentioned, all good then!
I just have one suggestion which is to mention dropping support for GMT 6.3 (as mentioned above at #3361 (comment)). Assuming we want to do that in v0.14.0?
We can do it either in v0.14.0 or v0.15.0. Actually, I'm considering whether we should still allow users to use GMT 6.3 but only GMT 6.4 and above are officially supported. It means we will test GMT 6.4, 6.5, and dev, but still allow people to install PyGMT v0.14.0 or later with GMT 6.3.0.
I just have one suggestion which is to mention dropping support for GMT 6.3 (as mentioned above at #3361 (comment)). Assuming we want to do that in v0.14.0?
We can do it either in v0.14.0 or v0.15.0. Actually, I'm considering whether we should still allow users to use GMT 6.3 but only GMT 6.4 and above are officially supported. It means we will test GMT 6.4, 6.5, and dev, but still allow people to install PyGMT v0.14.0 or later with GMT 6.3.0.
Sure, we can have a transition period where 6.3 still partially works. Do we keep the compatibility code around though?
Edit: I had a quick look and it seems like the GMT 6.3 compatibility code is only in the tests? So should be ok to remove in the next release.
Just saw that we have in the release draft:
- v0.14.0
Figure.grdcontour
: Remove parameterinterval
, uselevels
instead (FutureWarning raised since PyGMT v0.12.0)
But in the codes it's actually v0.16.0 in which interval
is removed:
https://github.com/GenericMappingTools/pygmt/blob/1ff03a3c79401ed841c482da6455e816e2ab3bae/pygmt/src/grdcontour.py#L21
So we probably should move this down to v0.16.0 in the release draft?
I think yes.
I just made the v0.13.0 release and a discussion page (#3426) is automatically created.
Thanks for handling and making the release @seisman!
GMT forum (do this announcement first! draft on https://hackmd.io/@pygmt. requires moderator status) https://hackmd.io/V54IxrZGRv2eLr7z6n-7yQ
The draft looks good to me except for two minor comments about the memorial session.
I have addressed this two minor comments now. Maybe we leave this draft for some more time, and post it on Friday afternoon / evening on the forum?
Just posted the announcement on the GMT forum at https://forum.generic-mapping-tools.org/t/pygmt-v0-13-0-released/5264.
Looks like we nearly done with this release π. Thanks all for your efforts and work ππ!
Who is going to do the upload on ResearchGate?
I think yes.
OK. I have update the release draft and also the one for v0.12.0 to avoid confusions.
Who is going to do the upload on ResearchGate?
This is my first time adding a code to ResearchGate. I have to manually add all 18 authors, which is painful.
We're done with the v0.13.0 release and let's move to v0.14.0. Thank you all for your work on this release. π
We need to discuss the expected release date for the v0.14.0 release. Considering the AGU fall meeting and the GMT/PyGMT workshop in December, I think we have the following options for the release date:
People may be busy with preparing materials for the AGU meeting or workshop in late Nov. and early Dec, so they may not be good choices.
I'm OK with either option 1 or 4. I think it depends on whether there are new features or bug fixes that affect the workshop materials.
Done at https://www.researchgate.net/publication/383826612_PyGMT_A_Python_interface_for_the_Generic_Mapping_Tools_v0130. This is my first time adding a code to ResearchGate. I have to manually add all 18 authors, which is painful.
Thanks for doing the ResearchGate upload @seisman! Hm. I did not add code to RG yet. Maybe @michaelgrund knows a way to do this more convenient, as he has done the uploads of the last releases. By looking at https://github.com/GenericMappingTools/pygmt/issues/2621#issuecomment-1669669166 and https://github.com/GenericMappingTools/pygmt/issues/2621#issuecomment-1677960237 it seems relevant to follow the other contributors to add the entry probably.
We need to discuss the expected release date for the v0.14.0 release. Considering the AGU fall meeting and the GMT/PyGMT workshop in December, I think we have the following options for the release date:
- Early November
- Late November
- Early December (before AGU)
- Late December (after AGU)
People may be busy with preparing materials for the AGU meeting or workshop in late Nov. and early Dec, so they may not be good choices.
I'm OK with either option 1 or 4. I think it depends on whether there are new features or bug fixes that affect the workshop materials.
I will be quite busy in the next weeks / months, and will probably attend another conference in November. So, it is very likely that I can only help with smaller task if we do the release before AGU.
I've set the v0.14.0 release date to 2024/12/31. Let's see what we can have in the next two months.
I've set the v0.14.0 release date to 2024/12/31. Let's see what we can have in the next two months.
Sounds good :rocket:!
Release: v0.13.0 Scheduled Date: 2024/09/05 Pull request due date: 2024/09/03 DOI:
10.5281/zenodo.13679420
Priority PRs/issues to complete prior to release
Before release:
grep --include="*.py" -r 'remove_version="vX.Y.Z"' pygmt
from the base of the repository @seismanpygmt.show_versions()
as well as notes in Common installation issues and Testing your install regarding GMT-Ghostscript incompatibility @seisman10.5281/zenodo.13679420
@seismandoc/_static/version_switch.js
for documentation switcherCITATION.cff
and BibTeX at https://github.com/GenericMappingTools/pygmt#citing-pygmtdoc/minversions.md
doc/minversions.md
make codespell
to check common misspellings. If there are any, either fix them or add them toignore-words-list
inpyproject.toml
Release:
After release:
[x] Update conda-forge pygmt-feedstock [Done automatically by conda-forge's bot, but remember to pin SPEC0 versions]
[x] Bump PyGMT version on https://github.com/GenericMappingTools/try-gmt (after conda-forge update) https://github.com/GenericMappingTools/try-gmt/pull/54
[x] Announce the release on:
[x] ResearchGate (after forum announcement, add new version as research item via the code category, be sure to include the corresponding new Zenodo DOI) https://www.researchgate.net/publication/383826612_PyGMT_A_Python_interface_for_the_Generic_Mapping_Tools_v0130
[x] Party :tada: (don't tick before all other checkboxes are ticked!)