Release GMT 6.3.0

[maxrjones]

Version: 6.3.0

Scheduled date: November 19, 2021

Before release:

• [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] 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] 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 bundle (@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] make announcements on the GMT instagram
• [x] update links on the main site (News, Download & Documentation)

After release:

• [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, @meghanrjones) (https://github.com/conda-forge/gmt-feedstock/pull/178)
• [x] update homebrew formula (@claudiodsf, @seisman) https://github.com/Homebrew/homebrew-core/pull/89808
• [x] update macports ports (@remkos, @seisman) https://github.com/macports/macports-ports/pull/13070
• [x] update the RPM repository (@seisman)
• [x] update the try-gmt Jupyter lab (@weiji14, @seisman) (https://github.com/GenericMappingTools/try-gmt/pull/32)
• [x] update winget manifest file (@seisman) https://github.com/microsoft/winget-pkgs/pull/35396

---

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

[PaulWessel]

I think the task "run src/gmtmake*.sh to update some .c and .h files" needs to move up before we run tests,no? Same with the gs check since test results might be questionable with a bad gs version.

[PaulWessel]

To pass the "tests pass" checkbox I think we mean pass in the CI after sending magic code to run the full tests?

[PaulWessel]

Note: The mex build must be done on Intel since Matlab is not M1 native yet.

[maxrjones]

To pass the "tests pass" checkbox I think we mean pass in the CI after sending magic code to run the full tests?

Yes

[PaulWessel]

Hi @joa-quim, please run your Julia tests and if pass check the box above. We are hoping to get 6.3 out this week.

[joa-quim]

They just passed 3 hours ago in Ubuntu

https://github.com/GenericMappingTools/GMT.jl/runs/4240270774?check_suite_focus=true

[PaulWessel]

Are we doing any -rc1 this time around?

[maxrjones]

Are we doing any -rc1 this time around?

I don't think much was gained from the rc efforts last time.

[PaulWessel]

I think install.md looks fine so I checked that box.

[PaulWessel]

Do we know how to manage GMT_LIB_SOVERSION and when to increase it? I think (?) This specifies the shared library minimum version of something? We have not changed it since 6.0.0. Or is it the min version that the gmt executable can link with? Or a statement that the API has not changed? Do any of you know, @joa-quim and @meghanrjones and @seisman ? I guess the default is to leave it at 6.

[Esteban82]

I could make an announcements on Instragam (based on ones of twitter/forum).

• [ ] make announcements on the GMT instagram

[maxrjones]

Thanks @Esteban82! I'll add this to the workflow so that it is automatically is added to the checklist next time.

[PaulWessel]

FYI, the zenodo DOI will have two new authors: @meghanrjones and @Esteban82 [Sorry, I forgot to add Meghan last time...]. 10.5281/zenodo.5708769.

[PaulWessel]

Can I add 6.3 to doc/rst/_static/version_switch.js and then check the code freeze button, @meghanrjones ?

[maxrjones]

Can I add 6.3 to doc/rst/_static/version_switch.js and then check the code freeze button, @meghanrjones ?

Just finishing the changelog - I can include the version_switch in that PR.

[maxrjones]

Regarding the check/set values in cmake/ConfigDefault.cmake boxes, doesn't this need to get committed to the repo before the tag gets pushed?

[PaulWessel]

For those tiny changes I committed directly to master .... Most were already set (year, version)

[PaulWessel]

I will to a PR to undo once we release.

[maxrjones]

Ah I see, thanks. You can PR or commit directly after, whichever you see fit.

[PaulWessel]

Shall we check the code freeze and move along to the release steps?

[PaulWessel]

@joa-quim do you build from the tar ball or master directly? If the latter could you please start building the Win installers? Otherwise tarballs will be ready soon.

[PaulWessel]

I've placed the src tarballs and the arm bundle. @meghanrjones I need to you do the x86 bundle since mine fails to code sign...

[PaulWessel]

Suggestions for release template changes:

1. Break up the multiple tasks like building M1 and Intel bundle into two separate tasks
2. Break up the testing of the installers and bundles and tarballs into separate tasks.

We could get help from more people to test a tarball vs testing a Win installer etc. Also, hard to check the current boxes without lots of back/forth on who is doing what.

[maxrjones]

build-release.sh: Report sha256sum per file
beb3825fba450fe60b596cb467be3af4bb7eec06ed1d61bafa3304e46c71ceef  gmt-6.3.0-darwin-x86_64.dmg

I can configure the release-test-bot to test the various installers once the windows ones are at /export/ftp1/ftp/pub/gmtrelease.

[PaulWessel]

And I forgot:

a5d78d43df2bb405fcc9a564bea7438de877e969a0912f022d15c6bb8199185d  gmt-6.3.0-darwin-arm64.dmg
8a42972a70e24bb2d9b793ad5be6c048c468d701758b0bdfed546dbe84c40a97  gmt-6.3.0-src.tar.gz
1cbd27c974afda848c829cd16eb6f4270e8aa5263ff57bc64e7a4fe760bc0dac  gmt-6.3.0-src.tar.xz

[joa-quim]

http://fct-gmt.ualg.pt/tmp/gmt-6.3.0-win64.exe 279db7f4f07b14e2accd9d336d496a5f811ef24f http://fct-gmt.ualg.pt/tmp/gmt-6.3.0-win32.exe a3e2eda2ced31df7024a843d2d91c6b7832e6066

[PaulWessel]

Thanks, @meghanrjones can take it from there?

[maxrjones]

I started some CI tests on the bundles over at https://github.com/GenericMappingTools/gmt-release-testbot/pull/33. @PaulWessel, did you test that you could build successfully from the source tarballs? Also, can you confirm that the arm bundle worked for you (I don't think we have a way for a check on this)?

[PaulWessel]

I double-clicked on the GMT 6.3.0 arm application and ran

gmt grdimage @earth_relief -RFR -I+d -B -png map

which exercises both the remote files, DCW and gs, and it worked fine. Yesterday I also ran ex31 which uses fonts to ensure no monkey-business due to the change to GS_LIB. I realize that none of the Latex support in GMT will work in the bundle since we do not (and will not!) distribute the huge texlive stuff. But users will get a message about latex and dvips not found at least. Still, we should not this somewhere.

As for tarball I extracted and ran the Cmake and build sequence successfully. I did not try to make any plots with this version but just did gmt --version.

[PaulWessel]

I also ran a coast command to test that GSHHG worked in the ARM bundle.

[maxrjones]

Great, thanks Paul!

[maxrjones]

I checked off the testing box based on Paul's results and the CI results from https://github.com/GenericMappingTools/gmt-release-testbot/actions/runs/1479168234. The batch animation test fails, but that was also the case for 6.2.0.

[PaulWessel]

Hi @joa-quim we need to redo the installer builds:

1. I forgot to release DCW 2.0.1, now done
2. We fixed the subtle gmt_plot.c bug that crashed @anbj movie examples

I'll be building M1 bundle and tarballs soon.

[anbj]

@PaulWessel Yes, perfect! movie example now runs fine.

[joa-quim]

Same links, new SHAs

http://fct-gmt.ualg.pt/tmp/gmt-6.3.0-win64.exe 48d8cfcfb5b7707b5ae7c2a62304533fa082f838 http://fct-gmt.ualg.pt/tmp/gmt-6.3.0-win32.exe bf388b469bbf2a34fcd073c4c74b505ed34efc46

Note, I saw 4 or 5 updates in last git pull. We really should stop doing this. Last version (6.2.0) broke Julia wrapper badly due to a last change and I had to do gymnastics in the wrapper to hide it. And before that I remember at least one other release where I, only by miracle (revealed later) avoid a broken release. Once we finish a release, we finish it. All changes go to next one.

[PaulWessel]

17952484db64e16ce429db5f01c10322de4e6aeed0676500d2d7ec7b5778c198 gmt-6.3.0-darwin-arm64.dmg 2cd073d8b1f11b87a59b38aa7aaf8e39c7940d2b55a46a3267e23802ec8a08d1 gmt-6.3.0-src.tar.gz 69e29b62ee802a3a64260d6a1e023f1350e3bf4070221aa1307bf8a9e56c1ee5 gmt-6.3.0-src.tar.xz

[PaulWessel]

Agree, but we fixed a really bad bug that SEGB on Inux and probably Windows.

[joa-quim]

That was probably there even before 6.2 and last time we shipped a broken 6.2 for Julia (and MEX) usage.

[maxrjones]

ad5550389fd9f4a849618ba226f08a6dd39222fc88d1f69887ef9c23c643ba38 gmt-6.3.0-darwin-x86_64.dmg

[PaulWessel]

That was probably there even before 6.2 and last time we shipped a broken 6.2 for Julia (and MEX) usage.

Yes, this is an older bug but it was fatal on Linux and possibly Windows. So I think good to have that found (via valgrind) and plugged. I agree we should be very cautious with last-minute change though. Can you remind me what the issue was with 6.2 since I cannot recall this incident.

[maxrjones]

The installers and tarballs are placed on the ftp. @PaulWessel, should I push the tag and make the release on GitHub?

[PaulWessel]

Yep, go for it!

[maxrjones]

Anyone interested in doing the Forum announcement? I can post on Twitter and update the website after the forum and zenodo are updated.

[PaulWessel]

Sure, I can post something on the forum shortly.

[PaulWessel]

Forum and Zenodo publishing done.

[maxrjones]

Should we remove the 6.3 branch part from the checklist? I thought from last release that this is only done if it is determined that we need a patch release.

[PaulWessel]

Yes, it is quite hypothetical.

[PaulWessel]

Is @Esteban82 doing the Instagram then?

[Esteban82]

Yes I will.

[joa-quim]

Can you remind me what the issue was with 6.2 since I cannot recall this incident.

Using -i from MEX or Julia crashes the calling environment. That is due to a change introduced during the RC stage.