Release GMT 6.2.0

[maxrjones]

Version: 6.2.0

Scheduled date: June 05, 2021

Before release:

• [x] check if all tests pass on macOS, Linux and Windows
• [x] check if other GMT-derived projects work well
  • [x] MB-System (@PaulWessel)
  • [x] GMTSAR (@PaulWessel)
  • [x] GMT.jl (@joa-quim)
  • [x] PyGMT (@leouieda, @seisman, @weiji14)
  • [x] gmtmex (@PaulWessel, @joa-quim)
• [x] reserve a DOI on zenodo (@PaulWessel)
• [x] run src/gmt_make_*.sh to update some .c and .h files
• [x] run admin/gs_check.sh to test if latest ghostscript version works
• [x] update changelog
• [x] check installation instructions in INSTALL.md
• [x] check if there are any warnings when building the documentation
• [x] add one new entry in doc/rst/_static/version_switch.js if it's a minor release
• [x] check/set values in cmake/ConfigDefault.cmake
  • [x] GMT_VERSION_YEAR is current year
  • [x] GMT_PACKAGE_VERSION_* is correctly set
  • [x] GMT_LIB_SOVERSION is correctly set
  • [x] set GMT_PUBLIC_RELEASE to TRUE
  • [x] update GMT_VERSION_DOI
• [x] freeze codes and commit all changes to GitHub

Release:

• [x] create source tarballs (tar.gz and tar.xz) (@PaulWessel, @meghanrjones)
• [x] create macOS bundles (arm64 and intel) (@PaulWessel, @meghanrjones)
• [x] create Windows installers (win32 and win64) (@joa-quim)
• [x] check if the source tarballs, macOS bundle and Windows installers work well
• [x] upload source tarballs, macOS bundle, Windows installers to the GMT FTP (@PaulWessel, @meghanrjones)
• [x] update README and VERSION files on the GMT FTP (@PaulWessel)
• [x] make a tag and push it to github (Must be done after uploading packages to the GMT FTP)

  # checkout master (for minor releases) or 6.x branch (for patch releases)
  git checkout XXXX
  # create the tag x.x.x
  git tag x.x.x
  # Push tags to GitHub
  git push --tags

• [x] make a GitHub release. The GitHub Actions automatically create a draft release after pushing the tag to github. We need to go to the GitHub Release page, and review it manually.
  • [x] 7 files are attached as release assets (2 source tarballs, 4 installers and 1 checksum file).
  • [x] download the checksum file and check if the checksums are correct
  • [x] edit the draft release, set the target to the correct tag, and publish the release
• [x] upload the tarball to zenodo (@PaulWessel)
• [x] make announcements in the GMT forum
• [x] make announcements on the GMT twitter
• [x] update links on the main site (News, Download & Documentation)

After release:

• [x] create branch 6.x for bug-fixes if this is a minor release (i.e. create branch 6.2 after 6.2.0 is released)

  git checkout master
  git checkout -b 6.2
  git push --set-upstream origin 6.2

• [x] update GMT_PACKAGE_VERSION_* in cmake/ConfigDefault.cmake
• [x] comment the set (GMT_PUBLIC_RELEASE TRUE) line
• [x] commit changes to GitHub

3rd-party update

Volunteers needed! Please let us know if you volunteer to help to maintain GMT in these 3rd-party tools.

• [x] update conda-forge feedstock (@leouieda, @seisman, @weiji14) (https://github.com/conda-forge/gmt-feedstock/pull/153)
• [x] update homebrew formula (@claudiodsf, @seisman) (https://github.com/Homebrew/homebrew-core/pull/78822)
• [x] update macports ports (@remkos, @seisman) (https://github.com/macports/macports-ports/pull/11253)
• [x] update the RPM repository (@seisman) (Done in https://github.com/GenericMappingTools/gmt-rpm/pull/6, except CentOS 8, see https://github.com/GenericMappingTools/gmt-rpm/issues/7)
• [x] update the try-gmt Jupyter lab (@seisman) (https://github.com/GenericMappingTools/try-gmt/pull/20)
• [x] update the AUR repository (@holishing)
• [x] update winget manifest file (@seisman) (https://github.com/microsoft/winget-pkgs/pull/16400)

---

• [x] Party :tada: (don't tick before all other checkboxes are ticked!)

[PaulWessel]

Need @joa-quim to do his GMT.jl tests.

[holishing]

Detail: Version number in 1st task of “After Release” should be corrected. :)

[PaulWessel]

ARM64 bundle completed and uploaded to gmtrelease dir:

b5bcb8bffb4db8a42fcc08012a04399ccc6070f3a4b8ee36975f8c0e74b0bc4f gmt-6.2.0-darwin-arm64.dmg

[maxrjones]

c5038aff92be4ac9df1fc2f06c1b23f5eec9e111bfe596c7ae2b47305ac929a9  gmt-6.2.0-darwin-x86_64.dmg
ab7062912aeead1021770fad4756e0a99860fde8ea9b428fb00c22fa15a3bbfc  gmt-6.2.0-src.tar.gz
a01f0a14d48bbc0b14855670f366df3cb8238f0ccdfa26fe744968b4f1c14d54  gmt-6.2.0-src.tar.xz

[PaulWessel]

Hi @joa-quim, please build the Windows installer and make it available, with checksum.

[joa-quim]

http://fct-gmt.ualg.pt/tmp/gmt-6.2.0-win32.exe SHA1 hash of .\gmt-6.2.0-win32.exe: bc44e8ecfe2b5c1962d7f1a17f5d1e39aedd71b2

http://fct-gmt.ualg.pt/tmp/gmt-6.2.0-win64.exe SHA1 hash of .\gmt-6.2.0-win64.exe: 5bac8d815c8a4d78c7cb2c59e984d68d32c8b3ae

[PaulWessel]

Thanks, we should now do some testing that these are all functioning. I have placed them in the gmtrelease folder and verified the sha1 values.

[PaulWessel]

To the CI people: Might it be possible to device a simple cloud-run test of the installers? I.e., have the CI download an installer, install GMT, and run a some basic steps? RIght now testing the installers requires one to have access to a machine or VM that supports the various OS. Having lent my Win laptop to a student I have no Win here at home, just mac intel and arm, and maybe CentOS in a VM on the mac.

[seisman]

We already have a test bot (https://github.com/GenericMappingTools/gmt-release-testbot) which can test the installer on various OS. I'll trigger testing on the installers now.

[PaulWessel]

Great, perhaps the checklist can remind us of what that entails for next time?

[seisman]

Could you please remind me what's the URL link of the "gmtrelease folder"?

[seisman]

Could you please remind me what's the URL link of the "gmtrelease folder"?

I just found it.

[joa-quim]

I tested the win32 installer in a clean VM and no problems running gmt psxy

[PaulWessel]

Great, I usually at least run your installers on my Dell but no Dell no install. But best if this is done cleanly in the cloud on all OS.

[seisman]

Tested the x86_64 macOS bundle on macOS 10.15 and 11.0, and the win32 and win64 installers, they all look good.

Currently, we can't test the ARM bundle.

[PaulWessel]

I think that is OK for now. The arm bundle could be labelled experimental - it already has a weakness in that it is suffering from docutils bug (I cannot install a prior version in macports since it was a new install).

[PaulWessel]

Any objections to moving down the to-do list with uploading the GMT ftp? I can get us down so the next step is the Make GitHub Release.

[seisman]

Any objections to moving down the to-do list with uploading the GMT ftp? I can get us down so the next step is the Make GitHub Release.

Looks good to me.

[PaulWessel]

OK, tag done, now waiting for the CI to do the release on github.

[PaulWessel]

Got email saying they all failed... What I screw up?

[PaulWessel]

I did place the files on the GMT ftp server. Time-outs? I think I set the permissions correctly too.

[maxrjones]

curl failed, I think on the win64 installer. Not sure why but it does not look like a time-out.

[seisman]

I just retrigged the CI. Let's see if it works.

[seisman]

The command fails locally for me:

curl -O ftp://ftp.soest.hawaii.edu/gmt/bin/gmt-6.2.0-win64.exe

[PaulWessel]

pwessel@ftp:/export/ftp1/ftp/pub/gmt-> ls -l /export/ftp1/ftp/pub/gmt/gmt-6.2.0-*
-rw-r--r-- 1 pwessel wessel 69312429 Jun  5 10:38 /export/ftp1/ftp/pub/gmt/gmt-6.2.0-src.tar.gz
-rw-r--r-- 1 pwessel wessel 56104264 Jun  5 10:38 /export/ftp1/ftp/pub/gmt/gmt-6.2.0-src.tar.xz

pwessel@ftp:/export/ftp1/ftp/pub/gmt-> ls -l /export/ftp1/ftp/pub/gmt/bin/gmt-6.2.0-*
-rw-r--r-- 1 pwessel wessel 182481805 Jun  5 10:39 /export/ftp1/ftp/pub/gmt/bin/gmt-6.2.0-darwin-arm64.dmg
-rw-r--r-- 1 pwessel wessel 192969554 Jun  5 10:39 /export/ftp1/ftp/pub/gmt/bin/gmt-6.2.0-darwin-x86_64.dmg
-rwx--x--x 1 pwessel wessel 127320052 Jun  5 10:39 /export/ftp1/ftp/pub/gmt/bin/gmt-6.2.0-win32.exe
-rwx--x--x 1 pwessel wessel 176260188 Jun  5 10:39 /export/ftp1/ftp/pub/gmt/bin/gmt-6.2.0-win64.exe

[PaulWessel]

Looks like I do not have permission to change those to read and exe. OK, finally:

ls -l /export/ftp1/ftp/pub/gmt/bin/gmt-6.2.0-* -rw-r--r-- 1 pwessel wessel 182481805 Jun 5 10:39 /export/ftp1/ftp/pub/gmt/bin/gmt-6.2.0-darwin-arm64.dmg -rw-r--r-- 1 pwessel wessel 192969554 Jun 5 10:39 /export/ftp1/ftp/pub/gmt/bin/gmt-6.2.0-darwin-x86_64.dmg -rwxr-xr-x 1 pwessel wessel 127320052 Jun 5 10:39 /export/ftp1/ftp/pub/gmt/bin/gmt-6.2.0-win32.exe -rwxr-xr-x 1 pwessel wessel 176260188 Jun 5 10:39 /export/ftp1/ftp/pub/gmt/bin/gmt-6.2.0-win64.exe

[seisman]

Draft release is available at https://github.com/GenericMappingTools/gmt/releases.

[PaulWessel]

I added the sha256 values to the tables and saved the draft (but not released). I am not sure what the " set the target to the correct tag" means here. Is it not already set to what we want (6.2.0)? if so, please review and either hit release or tell me to.

[seisman]

I've published the release!

I added the sha256 values to the tables and saved the draft (but not released).

This could be done automatically by the CI workflow. We can improve the CI workflow later.

I am not sure what the " set the target to the correct tag" means here. Is it not already set to what we want (6.2.0)?

Usually, the target is set to the correct tag automatically.

[PaulWessel]

Zenodo tarball w/ new DOI published.

[PaulWessel]

Once we are all done releasing 6.2 we are back to the issue of having a 6.2 branch for a future 6.2.x bug-fixing update. I guess we should do this regardless of any plans for 6.2.1 since we have a long list of WIP PRs with new features and once we add those to master we cannot easily make 6.2.1 to address some catastrophic bug. Yet, the memories of back-porting and merging to two branches are still lingering. Thoughts?

[PaulWessel]

Looks like documentation links to 6.2 is not working?

[PaulWessel]

So the doc link is actually 6.2.0 but previously we have 6.1 and 6.0. So when/how to we get to set 6.2.0 to 6.2 and use that?

[seisman]

So the doc link is actually 6.2.0 but previously we have 6.1 and 6.0. So when/how to we get to set 6.2.0 to 6.2 and use that?

It's a bug introduced in the migration from Azure Pipelines to GitHub Actions (https://github.com/GenericMappingTools/gmt/pull/4530, after releasing 6.1.1), and it only affects official releases so we won't know until now.

I'll make a quick fix and try to improve the script later.

[PaulWessel]

OK, sounds good. I approved the PR.

[seisman]

OK, sounds good. I approved the PR.

Now the 6.2 documentation is live (https://docs.generic-mapping-tools.org/6.2/).

Once we are all done releasing 6.2 we are back to the issue of having a 6.2 branch for a future 6.2.x bug-fixing update. I guess we should do this regardless of any plans for 6.2.1 since we have a long list of WIP PRs with new features and once we add those to master we cannot easily make 6.2.1 to address some catastrophic bug. Yet, the memories of back-porting and merging to two branches are still lingering. Thoughts?

I think so.

[joa-quim]

The releasing process has become a very heavy thing and I doubt we will have a 6.2.1 release. We may create one such branch but it won't be used.

[PaulWessel]

I agree, but my thinking is that either we create a 6.2 branch now and immediately can start approving and merging in those WIP branches, or we wait to merge any of them for 1-2 weeks to make sure there is nothing fatal in 6.2.0 that requires 6.2.1. Seems the first option is better and if not needed then it can be deleted, no?

[seisman]

I agree, but my thinking is that either we create a 6.2 branch now and immediately can start approving and merging in those WIP branches, or we wait to merge any of them for 1-2 weeks to make sure there is nothing fatal in 6.2.0 that requires 6.2.1. Seems the first option is better and if not needed then it can be deleted, no?

Actually we even don't have to create a 6.2 branch now. We can merge the WIP branches into master and target for the 6.3.0 release. If any fatal bugs are reported in the next few weeks and we decide to have the 6.2.1 release, we can create the 6.2 branch from the 6.2.0 tag (not the latest master), and then backport any PRs (both new PRs and old PRs that are already merged into master) into the 6.2 branch.

[PaulWessel]

OK, that sounds like a plan: No 6.2 branch unless needed, else moving towards 6.3.

[PaulWessel]

I will check the 6.2 branch boxes above as if we did then, then make a PR taking us to master again.

[PaulWessel]

OK, we are back to the situation where developers can merge approved branches to master. Now the work shifts to the 3rd parties:

Homebrew: @claudiodsf and @seisman MacPort: @remkos and @seisman AUR repo: @holishing

plus the python stuff with @leouieda @weiji14 @meghanrjones @seisman

[maxrjones]

Link to twitter post: https://twitter.com/gmt_dev/status/1401370141523337217

[holishing]

AUR repo has shifted version 6.2.0.

[seisman]

FYI, the Homebrew formulae has been updated to 6.2.0, and If I understand it correctly, it now supports ARM.

[seisman]

Macports has updated GMT to 6.2.0.

[PaulWessel]

Great, congrats all! I guess we can close this issue then?

[maxrjones]

Great work, everyone!