Release GMT 6.1.0

[seisman]

Version: 6.1.0
Scheduled date: July 1, 2020

Before release:

• reserve a DOI on zenodo (@PaulWessel)
• run src/gmt_make_*.sh to update some .c and .h files
• check if all tests pass on macOS, Linux and Windows
• run admin/gs_check.sh to test if latest ghostscript version works
• update changelog
• update INSTALL.md
• check if there are any warnings when build the documentation
• check/set values in cmake/ConfigDefault.cmake
  • GMT_VERSION_YEAR is current year
  • GMT_PACKAGE_VERSION_* is correctly set
  • GMT_LIB_SOVERSION is correctly set
  • set GMT_PUBLIC_RELEASE to TRUE
  • update GMT_VERSION_DOI
• freeze codes and commit all changes to GitHub

Release:

• create source tarballs (tar.gz and tar.xz) (@PaulWessel)
• create macOS bundle (@PaulWessel)
• create Windows installers (win32 and win64) (@joa-quim)
• check if the source tarballs, macOS bundle and Windows installers work well
• upload source tarballs, macOS bundle, Windows installers to the GMT FTP (@PaulWessel)
• make a tag and push it to github (Must be done after uploading packages to the GMT FTP)

  git tag x.x.x
  git push --tags
  

• make a GitHub Release.
  GitHub actions automatically create a draft release for us after pushing the tag.
  We need to check if everything is OK and then publish the release.
• upload the tarball to zenodo (@PaulWessel)
• update README and VERSION files on the GMT FTP (@PaulWessel)
• make announcements in the GMT forum (https://forum.generic-mapping-tools.org/t/gmt-6-1-0-has-been-released/619)
• update links on the main site (News, Download & Documentation)

After release:

• create branch 6.x for bug-fixes if this is a minor release (i.e. create branch 6.1 after 6.1.0 is released)
• update GMT_PACKAGE_VERSION_* in cmake/ConfigDefault.cmake
• comment the set (GMT_PUBLIC_RELEASE TRUE) line
• commit changes to GitHub

3rd-party update

• update conda-forge feedstock (@leouieda, @seisman) (Update to GMT 6.1.0 conda-forge/gmt-feedstock#97)
• update homebrew formula (@claudiodsf, @seisman) (gmt 6.1.0 Homebrew/homebrew-core#57470)
• update fink package (@remkos)
• update macports ports (@seisman) (gmt6: update to 6.1.0 macports/macports-ports#7648)
• update the RPM repository (@seisman)

---

• Party 🎉 (don't tick before all other checkboxes are ticked!)

[PaulWessel]

Following our latest contributor chat, we agreed on periodic releases, twice a year, and we probably wanted to release them not the week before AGU, despite the historical precedence of doing that numerous times in the olden days...
Since 6.1 is way overdue and has lots of new stuff, it is probably fine to aim for June 1 as a firm release date and then we start the 6-month cycle on Oct 1, 2020, followed by April and October releases in future years. We will push the 3-D grid implementation to the October release.

[PaulWessel]

June 1 is coming up. We need to make decision on whether or not some planned features shall go in now or be saved for 6.2:

• GMT themes. The mechanism is implemented and works well. Defining what modern mode (and others) contain is not completed. Relatively easy to pick some defaults; more work if we want to add some auto-scaling.
• Let -o take scales, offets, etc. Seems straightforward, but probably not essential for 6.1
• What else? Any lingering issues or PRs we want to finish. 10 days is short.

[seisman]

• GMT themes. The mechanism is implemented and works well. Defining what modern mode (and others) contain is not completed. Relatively easy to pick some defaults; more work if we want to add some auto-scaling.

I prefer to save it for 6.2 so that we have more time to test and tweak the settings for each theme.

• Let -o take scales, offets, etc. Seems straightforward, but probably not essential for 6.1

6.1 if it doesn't take much time to implement it.

• What else? Any lingering issues or PRs we want to finish. 10 days is short.

We have a 6.1.0 milestone. Most of the issues in the 6.1.0 milestone are to improve the documentation, but it's OK to save most of them for 6.1.1 or 6.2.0.

IMHO, these issues should be addressed before the 6.1.0 release:

• Make sure that the new gmt glue mechanism works well for external supplements (type 3 and 4?) (WIP Move this supplement to 6.1 support custom-supplements#2)
• Finalize the grid registration of global grid data Gridline-, pixel-, or both registrations? gmtserver-admin#35
• Organization of server data: Organization of server data gmtserver-admin#37
• Upload blue and black marbles to the GMT server

[joa-quim]

Thought in pushing #3287 but it really opens a can of works. We really should stop treating images as if they were grids and use GDAL to re-interpolate them.

[PaulWessel]

Given it is June 28 and no clear path to complete an agreeable themes roll-out and suitable period of testing, I think we will wait with themes until a later release when it can be more prepared. Thus, once #3550 can be merged I think we should build GMT 6.1.0rc1 immediately.

[PaulWessel]

When does SOVERSION change? Only when doing 7?

[PaulWessel]

Will be off the grid this morning (HI time) but back in afternoon. We need to make progress on the check-boxes. WIth GDAL 3.1.0 I think tests are OK.no @seisman? I checked the INSTALL.md since we did that yesterday.

[joa-quim]

My internet decided to go with GDAL 3.1.1 and is permanently crashing. Already contacted technical assistance but nothing improved. In this moment I'm using the phone hotspot.
We have the GEOS PR to solve. No problems with it but the CI is failing because the wrong lib is being detected (explained that in the issue)

[seisman]

When does SOVERSION change? Only when doing 7?

Yes, I think so. Currently, the library version is the same as the GMT version, i.e., libgmt.6.1.0.dylib.

WIth GDAL 3.1.0 I think tests are OK.

Yes.

[PaulWessel]

Can I check to box that says "freeze codes and commit all changes to GitHub" above, @joa-quim and @seisman ?

[seisman]

gmtmex/WL_example_3.sh still fails, but I'm OK to put it after 6.1.0 release.

[PaulWessel]

Let me have a look one last time. There are two issues:

1. The download to current directory means 24 Mb each time we test locally [don't care about CI taking longer]
2. The mysterious 0.01 scale factor taht seems OS dependent?