Release GMT 6.2.0rc2

[maxrjones]

Version: 6.2.0rc2

Scheduled date: May 24, 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] 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_PACKAGE_VERSION_SUFFIX to rcx
  • [x] set GMT_PUBLIC_RELEASE to TRUE
• [x] freeze codes and commit all changes to GitHub

Release:

• [x] create source tarballs (tar.gz and tar.xz) (@PaulWessel)
• [x] create macOS bundle (@PaulWessel)
• [x] create Windows installers (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)
• [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] 6 files are attached as release assets (2 source tarballs, 3 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] 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] comment the GMT_PACKAGE_VERSION_SUFFIX line 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)

---

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

[maxrjones]

Are there any outstanding issues that need to be addressed before rc2, @PaulWessel?

[joa-quim]

Why will there be an RC2? We are not even respecting RC1.

[maxrjones]

Why will there be an RC2? We are not even respecting RC1.

What do you mean we are not respecting RC1?

[joa-quim]

An RC is a release candidate. And it means that if no new bugs are found that RC is promoted to the final release. It means also that a feature freeze was in action and any new changes would have gone to the master branch but not included in the next release. We have not done that.

[maxrjones]

I do not recall any new features being added to the master branch since 6.2.0rc1. Which merged PRs do you consider to be new features? There were bug fixes since RC1 (e.g., https://github.com/GenericMappingTools/gmt/pull/5170, https://github.com/GenericMappingTools/gmt/pull/5178, and https://github.com/GenericMappingTools/gmt/pull/5181), which were the motivation for an RC2.

[joa-quim]

5124 for example touched quite a bit of code.

[PaulWessel]

Yes, it did, but it was in the interest of fixing a bug (the assumption that all angles are always longitudes). There was no way of fixing that without adding the new modifier so the user can specify what they plot. I think we only did bug-fixes even if some requires what is sort-of a new feature.

[PaulWessel]

I guess I do not know how to trigger the full tests in the CI. @meghanrjones or @seisman, did these run overnight so we can check the test-boxes, or do we need to set them up for a run first.?

[maxrjones]

They are triggered on any PRs that change src/**, test/**, share/**, doc/examples/**, doc/scripts/**, .github/workflows/**, or ci/**. The tests passed on the last PR that triggered the workflow (https://github.com/GenericMappingTools/gmt/pull/5193), so I will check the box.

[PaulWessel]

Hi @joa-quim, I successfully built gmtmex and MB system. Let me know if you have any concerns for those two, then please build GMT.jl and check that box for us.

[joa-quim]

All clear, but I've not tried MB. Too risky.

[seisman]

Looks good for PyGMT.

[seisman]

Any schedule for the rc2 release?

[PaulWessel]

With Meghan off on vacation this week and me dealing with e-graduation this Saturday I think we just have to do it early next week.

[maxrjones]

What is the status of the grdinterpolate bug with GMT.jl? It was not clear to me whether the recent PRs fixed the issues with grdinterpolate and whether there are further changes needed before rc2.

[PaulWessel]

It is tricky but I will need to reproduce the problem and it seems I cannot do so on macOS.

[PaulWessel]

Hi @joa-quim please check the GMT.jl box above if passes your tests.

[PaulWessel]

Pinging @joa-quim again on this - other than the grdinterpolate KEY change there are no memory layout changes or other KEY changes in 6.20rc2 so not sure what issues you are having and why they should hold up a release? Can you explain what the problems are in GMT.jl?

[joa-quim]

Issue solved. It was a trick regression that failed in my computer but passed in the CI tests.

[PaulWessel]

Great. Are you really gonna make me check that box or will you?

[maxrjones]

macOS tarballs and bundle are at ftp.soest.hawaii.edu://gmtrelease for testing:

f2bc929e4c427d8fd1cda4cf72746ec6457c8340167995453ffc0504fa989096  gmt-6.2.0rc2-darwin-x86_64.dmg
4ddb92b9a8e148444de7b4213bd42411d047f7ed5b1a96a05a4fd7f76880ba89  gmt-6.2.0rc2-src.tar.gz
4cf1798998205667004f7b70913da4b489f9a94c686c3fe021f79372451d4db5  gmt-6.2.0rc2-src.tar.xz

[PaulWessel]

Hi @joa-quim hoping you can build the win installer.

[joa-quim]

http://fct-gmt.ualg.pt/tmp/gmt-6.2.0rc2-win64.exe

[PaulWessel]

I have placed the win installer in the gmtrelease ftp with the other items. It would be great if @GenericMappingTools/core and @GenericMappingTools/gmt-contributors could give the RC2 installers a test. If all works OK then we have our 6.2.0 release soon.

[maxrjones]

@joa-quim, can you please post the sha256sum for the win64 installer?

[joa-quim]

SHA1 hash of .\gmt-6.2.0rc2-win64.exe: c9be92c397c41fb998eb904e61b6f502e5543d33

[maxrjones]

A quick test of each worked for me.

[PaulWessel]

I am wondering if we should add a 2nd bundle for those who have M1 macs to avoid the slowing down of conversion from arm to intel architecture. It is too hard yet to produce the universal binaries that have both architectures in them. I guess it is sort of win32 and win64 except the translation is more serious.

[PaulWessel]

I tested the bundle on my M1 mac and it worked fine of course.

[seisman]

I am wondering if we should add a 2nd bundle for those who have M1 macs to avoid the slowing down of conversion from arm to intel architecture

Sounds good to me.

[PaulWessel]

Then when I start trying I learn cannot install gcc9 form brew for M1 yet, so cannot build an Open-MP aware release. I could probably build one with Xcode and then without openMP. I will play with this to see if it is worth it.

[PaulWessel]

I am making edits to admin/build-release.sh so it could run for homebrew with xcode. One issue relates to proj7. On macports I need to add /opt/local/lib/proj7/share/proj. On homebrew I only find this in /opt/homebrew/Cellar/proj/7.2.1/share/proj. Is that the actual install place for proj7? Seems very version specific to me and in the "Cellar"? Am I missing a proj7 lib install command or something, @seisman ?

[seisman]

The version-independent share directory is /usr/local/share/proj for me. You should also be able to find it in /opt/homebrew/share/proj for your M1 Mac.

[PaulWessel]

Thanks, /opt/homebrew/share/proj worked.

[PaulWessel]

I am changing build-release.sh to use clang instead of gcc. This allows OpenMP builds on M1 architecture. I have build and uploaded an arm64 bundle under MacPorts. SHA256 codes:

f39faca480832602e85fb06c6f43c1a29ef68dc39015b790c88646229c88c26a gmt-6.2.0rc2-darwin-arm64.dmg

[joa-quim]

Does the M1 bundle build work with Julia? (the Intel doesn't because of the dependencies name screwing mess). Setting the right GMT_LIBRARY env variable should be enough to test it.

[PaulWessel]

Slow this morning. Just installing julia on the laptop now and will see.

[PaulWessel]

Life is an eternal struggle. I am not sure why this is happening, but there are those warnings that macports is confused about (version of framework). So I failed to build bundle on M1 because testing the compiler fails with this message:

    Run Build Command(s):/opt/local/bin/ninja cmTC_6720f && [1/2] Building C object CMakeFiles/cmTC_6720f.dir/testCCompiler.c.o
    FAILED: CMakeFiles/cmTC_6720f.dir/testCCompiler.c.o 
    /opt/local/bin/clang-mp-11   -flax-vector-conversions  -arch arm64 -o CMakeFiles/cmTC_6720f.dir/testCCompiler.c.o -c testCCompiler.c
    xcrun: error: unable execute utility "/opt/local/libexec/llvm-11/bin/clang" because it requires a newer version of macOS.
    ninja: build stopped: subcommand failed.

Of course, there is no newer version of macOS. This has to do with MacPorts yelling stupidity like this:

ld: warning: dylib (/opt/homebrew/lib/libfftw3f.dylib) was built for newer macOS version (11.3) than being linked (11.0)

It seems to b a macports limitation - I will dig around but that is what @meghanrjones is getting to I think. I may need to try clang-10 etc.

[maxrjones]

Yes, it is annoying.

[PaulWessel]

So Xcode 12.5 is out but did not show up as an update for me until I logged into Apple Developer and selected it to see it in teh App Store. After a long download I now have 12.5 which finally comes with MacOSX11.3.sdk. Doing the same on the other Macs here (it is a big download) and hope this will fix all the macports issues. @meghanrjones probably will want to do the same.

[PaulWessel]

Finally got Xcode 12.5 installed, updated MacPorts to 2.7, and more importantly added

set (CMAKE_OSX_DEPLOYMENT_TARGET "11.3")

to the cmake/ConfigUserAdvanced.cmake file. No more complaints about version linking mismatch. However, I would like to know why and what is setting 11.0 as the target under the hood somewhere (cmake?).

Now onwards to see if this works with Julia.

[joa-quim]

When I asked that I forgot about one detail. Julia itself is not distributed with an ARM build. Did you build it with Homebrew? Or running the Intel binary?

[PaulWessel]

Just learned right now that macports fails to install Julia on arm64. It is because gcc is not yet available and it apparently is built with gcc. So not sure if we will learn much, or if it would even work, having an intel julia run via rosetta1 try to call native arm64 GMT libraries...

[joa-quim]

I guess we'll have to wait. The curiosity was to see if the ARM bundle works where the Intel one fails.

[PaulWessel]

Yes, and Matlab 2021a is still Intel only so no point testing mex yet either.

[maxrjones]

CMAKE_OSX_DEPLOYMENT_TARGET - Specify the minimum version of the target platform (e.g. macOS or iOS) on which the target binaries are to be deployed

Would this impact the use of the binaries on older macOS's?

[PaulWessel]

Good question - and I have no older macos to test on.

[maxrjones]

Good question - and I have no older macos to test on.

Me neither. Unless @seisman knows off hand whether this setting impacts use on older macos, I could place a bundle built with set (CMAKE_OSX_DEPLOYMENT_TARGET "11.3") on the ftp site for the gmt-release-testbot to check with 10.15.

[seisman]

Good question - and I have no older macos to test on.

Me neither. Unless @seisman knows off hand whether this setting impacts use on older macos, I could place a bundle built with set (CMAKE_OSX_DEPLOYMENT_TARGET "11.3") on the ftp site for the gmt-release-testbot to check with 10.15.

I have no idea.

[PaulWessel]

Bundle ships all libs except more permanent system libraries whose function names do not change. I think it will be OK but your test sounds good.