Release GMT 6.0.0rc4

[PaulWessel]

Version: 6.0.0rc4

Before release:

• run src/gmt_make_*.sh to update some .c and .h files
• check if all tests pass on macOS, Linux and Windows
• update changelog
• update INSTALL.md
• build documentations and fix warnings if any
• 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
• 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)
• make a tag and push it to github

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

• go to GitHub Release and make a release. Remember to attach the source tarballs, macOS bundle and Windows installers.
• upload source tarballs, macOS bundle, Windows installers to the GMT FTP (@PaulWessel)
• update README and VERSION files on the GMT FTP (@PaulWessel)
• make announcements
• 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 homebrew formula (@claudiodsf, @seisman)
• update fink package (@remkos)
• update macports ports

---

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

[PaulWessel]

Was told by Wiley they are working on the galleys. We better do rc4 as training before the real release. I will start on the top.
Given my libcurl problem at UH, could you guys check that tests pass and check that box pelase? I will be busy until the early afternoon with other things.

[PaulWessel]

Hi @seisman, are you able to verify that tests pass and check taht box above? Also, we still dont have a changelog I think so I guess we can check that as well. I can run tests tonight at home and then I can build the tarballs and macOS bundle as well, and give links to those for @joa-quim to build win installers.

[seisman]

The tests are still running, see https://dev.azure.com/GenericMappingTools/GMT/_build/results?buildId=2381&view=results. It may take one more hour for the Windows tests.

[seisman]

@PaulWessel There are two new failing tests on Windows, ex29 and ex39.

[seisman]

Please check the attached two zip files.
ex29.zip
ex39.zip

[PaulWessel]

Looks OK to me. It is just switching from rainbow to turbo CPT so the images are almost entirely different, no? Do you see anything else? I would just update the orig PS.

[seisman]

But why these two tests pass on macOS and Linux?

[PaulWessel]

Well, they both fail for me under macOS. Perhaps the PS were not merged?

[seisman]

Running the scripts directly shows that the generated PS is different from the orig PS. Don't know why ctests didn't detect those for me.

[seisman]

gmt/doc/examples/gmtest.in

Lines 169 to 173 in 1e4c65a

	GLOBIGNORE="!(*.bat|*.ps|*.sh)"
	for file in "$src"/* ; do
	test -f "$file" && ln -s "$file" .
	done
	unset GLOBIGNORE

In the gmtest script of examples, it creates symbolic links for *.bat, *.sh and *.ps. Why does the *.ps symbolic links needed?

[seisman]

I believe the *.ps symbolic links are not needed at all. I've opened the PR #1513 to address the issue. After applying PR #1513, tests ex29 and ex39 fail for me.

[PaulWessel]

This is cryptic code from Florian. It sets up links to files in the original ex?? directory so that the script will run in the temporary build directory (some of them access local files and they would not be found). I am pretty sure I replaced the BLOBIGNORE since it nevern worked for me on macOS and we could not figure out why. But I agree in principle that the gm commands specifies the path to the original PS so why...

[PaulWessel]

At home I got on error in proj4.sh - presumably because macports installed goal 3.0.1 and there may be some subtle differences. How are things on your end?

[seisman]

I have one failing test on my local mac. GMT_App_P_2.sh fails because it can't find gmt_shell_functions.sh in its local directory.

The scheduled builds reports 0 failing tests on macOS, 1 failing test (mapproject/proj4.sh) on Linux. The Windows tests are still running, but should be good after update the orig PS of ex29 and ex39.

[PaulWessel]

Should the line

. gmt_shell_functions.sh

instead use the source directory path? E.g.

. ${GMT_SOURCE_DIR}/src/gmt_shell_functions.sh

[seisman]

Yes, it should be. The test failed suddenly because I removed GMT's bin from PATH, so . gmt_shell_functions.sh can't find gmt_shell_functions.sh.

[seisman]

There are 11 failing and 3 timeout tests on Windows. Look good to me.

[PaulWessel]

OK, all committed so checking the box.

[seisman]

The DOI of the G3 paper is out: 10.1029/2019GC008515, although it's not activated yet. I think we can update the citation information before 6.0.0rc4 is out.

[PaulWessel]

Should we enter that now before I build the tarballs or wait for 6.0.0?

[seisman]

OK, we can wait for the 6.0.0 release.

[PaulWessel]

Tarballs and macOS bundle built:

MD5 (gmt-6.0.0rc4-darwin-x86_64.dmg) = 752ae6d72f1d87ec8f5c98a3f00a6a9e
MD5 (gmt-6.0.0rc4-src.tar.gz) = bdb585c07e88c81f9da205b4f9f83102
MD5 (gmt-6.0.0rc4-src.tar.xz) = 517040d28c12d844e672cda5e7f97cce

In ftp:https://ftp.soest.hawaii.edu/pwessel/release

[seisman]

ftp:https://ftp.soest.hawaii.edu/pub/pwessel/release should be ftp:https://ftp.soest.hawaii.edu/pwessel/release

[joa-quim]

Win installers

https://www.dropbox.com/s/qfbebkhhfq0hyo5/gmt-6.0.0rc4-win64.exe?dl=1

https://www.dropbox.com/s/8l95av3cggcnsvr/gmt-6.0.0rc4-win32.exe?dl=1

[seisman]

@joa-quim

[joa-quim]

Damn it, forgot to change to Release build. Restarting

[joa-quim]

OK, please try again. The links are the same but the files should have been updated.

[seisman]

@joa-quim The win32 installer works, but the win64 one still has the same problem. Can you verify that you updated the win64 installer, and also provide the md5sum value.

[joa-quim]

Fine(ally). And the 32-bits

https://www.dropbox.com/s/vgf68rl45k2008r/gmt-6.0.0rc4-win32.exe?dl=0
b00d75fe393abc5222e450b58b8fface gmt-6.0.0rc4-win32.exe

[seisman]

I compiled the source package, and tested the macOS bundle and Windows installers. They all work well. For #1522, I think we can merge it into 6.0, then @PaulWessel can rebuild the tarballs and bundle. No need to rebuild the Windows installers for @joa-quim.

[PaulWessel]

Revsied tarballs and macOS bundle built after merging #1522:

MD5 (gmt-6.0.0rc4-darwin-x86_64.dmg) = 563e93978731d888dbf6ef044839c27e
MD5 (gmt-6.0.0rc4-src.tar.gz) = 4f0885ac9bcd13b2790ec354d7e73d35
MD5 (gmt-6.0.0rc4-src.tar.xz) = a2d25de23c27c28c572705b3e4b21948

In ftp:https://ftp.soest.hawaii.edu/pwessel/release

[seisman]

Tested again and all are good.

[seisman]

@PaulWessel I'll do the tag and release tasks if you think it's OK.

[PaulWessel]

Yes, please I think we are good to go.

[seisman]

Done in https://github.com/GenericMappingTools/gmt/releases/tag/6.0.0rc4. Unlike previous releases, I uploaded a gmt-6.0.0rc4-checksums.txt which lists the sha256sums of the 5 packages.

The reasons are:

1. md5sum is known to be insecure. sha256 is more secure.
2. sha256sum is needed by other package managers, e.g. homebrew, macports, and conda

Let me know if you prefer md5sum instead.

[PaulWessel]

No, I have no opinion on this. On macOS we can use shasum -a 256. We should then modify admin/build-release.sh to use shasum instead.

[PaulWessel]

I think I have done all the steps I can. The rest of the shopping list has to do with packaging, so @seisman and @leouieda may wish to do this now before we do it all again with 6.0.0.

[seisman]

The conda-forge build is ready, after applying the patches in #1527 and #1528. It's waiting for approval.

I also tested the homebrew recipe for 6.0.0rc4 locally, and it works fine.

[seisman]

I've submitted a new port gmt6 for macports, and is waiting for feedbacks and approval.

@remkos Maybe we can have a gmt6 fink package?

[seisman]

The conda-forge package is ready.

[PaulWessel]

Should the various recipes for fink, macports, homebrew and more go into the admin directory with build-release.sh etc? Seems to me these things belong with the distro (even though admin is not included in the tarballs and builds).

[seisman]

No need to include these recipes.

[PaulWessel]

So where do they live? Remko kept the fink recipe in the gmt tree (subversion, GMT4). Sandwellʻs student shared a macports recipe as a template with me and I will dig it out. I dont think we have a macports recipe otherwise.

[seisman]

The macports recipe is available from their github repository, i.e. https://github.com/macports/macports-ports/tree/master/science/gmt5, and I just submitted a gmt6 subport, which is still waiting for the maintainer's approval.

The fink recipes are also available for GMT4 and GMT5.

[PaulWessel]

I believe I need to sign up for a zenodo account to reserve a DOI for the 6.0.0 tarball. Are there benefits to use my GitHub account with zenodo? I get this page with questions:

Do I just click authorize here (i.e., grant access to gmt)?

[seisman]

Are there benefits to use my GitHub account with zenodo?

I think you can also sign up with your email and the connect you zenodo account with your GitHub account. No difference, but one less password to remember.

Do I just click authorize here (i.e., grant access to gmt)?

I believe you need to click the "grant" button after "GenericMappingTools" so that zenodo can read the GMT repositories.

[seisman]

Not sure if zenodo works for our case. As I understand it, when we make a github release, zenodo will automatically fetch the tarball, archive the repository and issue a DOI. However, if we want to reserve a DOI before a release, we have to upload the tarball to zenodo manually.

See zenodo/zenodo-docs-user#47 for a short discussion.

[PaulWessel]

Thanks, looks like I might as well get a separate non-GitHub-connected zenodo account.

[PaulWessel]

FYI, we are planning to get an SSL certificate and use https to get to the SOEST data server. Hopefully in a few days. I have already installed the data files on gmtserver so once it works we can switch over the redirect and update ConfigDefault.cmake.

[claudiodsf]

Hi, not sure why the homebrew formula checkbox is checked.

Anyway, I'll probably skip making a formula for rc4, since the homebrew maintainer prefers to wait on final release.

See this comment: Homebrew/homebrew-core#41119 (comment)

[claudiodsf]

On a second thought, I can still push a formula to my homebrew fork 😉

So, if you're interested in testing rc4 installation via homebrew, you can do:

brew install https://raw.githubusercontent.com/claudiodsf/homebrew-core/GMT6.0.0/Formula/gmt.rb

[seisman]

@claudiodsf I tested homebrew with rc4 locally, and it worked well for me. So I checked the checkbox.