Changelog entry for v0.2.0 #599
Conversation
Second minor release of PyGMT.
weiji14
force-pushed
the
changelog/v0.2.0
branch
from
d777533 to
c5cf4db
Compare
doc/changes.rst
Outdated
| .. image:: https://zenodo.org/badge/DOI/10.5281/zenodo.3781524.svg | ||
| :alt: Digital Object Identifier for the Zenodo archive | ||
| :target: https://doi.org/10.5281/zenodo.3781524 |
There was a problem hiding this comment.
Just to make sure someone (other than me) can do it, can one of @GenericMappingTools/python reserve a new version DOI under the PyGMT banner at https://zenodo.org/record/3930577? Just click on the green "New version" button (see sceenshot).
This will take you to a page where there should be a 'Reserve DOI' button somewhere. Click on that, and copy the DOI link here!
There was a problem hiding this comment.
Hmm, did you login with Github? I'm not quite sure how the permissions work on Zenodo. Might need to email them.
There was a problem hiding this comment.
Yes, I log in using my github acccout. I can see the PyGMT project in my account, but it's off by default.
.
After turning it on, I see:
There was a problem hiding this comment.
Ok, bit of a long story, but there were some double ups with the PyGMT release DOIs because I tried to reserve a DOI before a release, and put that in the release notes, but when we make a release, the automated Github integration would just ignore that reserved DOI and make a new one. So I had to email Zenodo and delete those duplicated DOIs. (Will forward you the email chain in a bit).
There was a problem hiding this comment.
Ok email sent. Just to clarify, there's 2 options that I know of to make a Zenodo DOI, each with pros/cons (see also FAQs at https://help.zenodo.org/):
- Use the automated Github integration:
- Pro: It's automated, publishing a release creates the DOI automatiically
- Con: We don't know the DOI number beforehand, so can't put it into the release notes. Also, I couldn't manage to link it to our current permanent/concept DOI at https://doi.org/10.5281/zenodo.3781524.
- Manually reserve a DOI (what was done for PyGMT v0.1.x):
- Pro: We know the DOI beforehand, so can put it into our release notes. Also more control with the metadata information.
- Con: It's not automated, I had to manually download the pygmt-v0.1.x.zip file, and upload it to Zenodo. Also as we found out, maybe it's linked only to my account?!!
So what should we do here?
There was a problem hiding this comment.
Maybe I'll just reserve the DOI again for this v0.2.0 release, and you (@seisman) or someone else can do it next time (will open an issue to keep track of it), since it might take a few days to email Zenodo and sort things out. Don't want to delay this release any longer.
doc/changes.rst
Outdated
| * Add a test for xarray shading (#581) | ||
| * Remove expected failures on grdview tests (#589) | ||
| * Redesign check_figures_equal testing function to be more explicit (#590) | ||
| * Cut Windows CI build time in half to 15 min (#586) | ||
| * Add a test for Session.write_data() writing netCDF grids (#583) | ||
| * Add a test to make sure shift_origin does not crash (#580) | ||
| * Add testing.check_figures_equal to avoid storing baseline images (#555) | ||
| * Eliminate unnecessary jobs from Travis CI (#567) | ||
| * Improve the workflow to test both GMT master and 6.1 branches (#554) | ||
| * Automatically cancel in-progress CI runs of old commits (#544) | ||
| * Github Actions CI for testing GMT master branch (#485) | ||
| * Remove the Stickler CI configuration file (#538) | ||
| * Cache GMT remote data as artifacts on Github (#530) | ||
| * Run style checks using GitHub Actions instead of Azure Pipelines (#519) | ||
| * Bump the required minimum GMT version to 6.1.0 (#507) |
There was a problem hiding this comment.
Some items in the maintenance can be merged into one item. For example, there are many items about the migration from Azure Pipelines to GitHub Actions.
There was a problem hiding this comment.
Ok just need to be careful that we keep the format as (#XYZ) otherwise our sed command won't work 😃
Also removed some unneeded entries. Co-Authored-By: Dongdong Tian <seisman.info@gmail.com>
|
I was just checking on some of my own uploads and it seems like only the original creator can upload a new version. This really sucks since we can't use the DOI versioning and have multiple release managers at the same time. I have sent them an email asking is there is a workaround and if not, making that a feature request. At the moment, it seems like we only have 2 options:
I don't think the GitHub automation is an option since it doesn't allow reserving the DOI. In the end, I found it more trouble than it's worth. One thing we could do is build our own automation using the Zenodo API. It lets us reserve DOIs and make uploads. But that could be a lot of work. |
|
Moved the comment above to #601 |
Description of proposed changes
Second minor release of PyGMT for a post GMT 6.1.1 world! Preview it live at https://pygmt-git-changelog-v020.gmt.vercel.app/changes.html. For reference, the previous changelog is at #504.
Changelog made by following the instructions at https://github.com/GenericMappingTools/pygmt/blob/master/MAINTENANCE.md#updating-the-changelog. The changelog itself includes the following sections:
TODO:
sed -i.bak -E 's$\(#([0-9]*)\)$(`#\1 <https://github.com/GenericMappingTools/pygmt/pull/\1>`__)$g' changes.rst.Relates to #587
Reminders
make formatandmake checkto make sure the code follows the style guide.doc/api/index.rst.