Release GMT 6.6.0

[seisman]

Version: 6.6.0

Scheduled date: XXX XX, 20XX

Before release:

• check if there are new SCM releases (@remkos) Update colormaps with SCM 8.0.1, adding naviaW #8654
• check if all tests pass on:
  • macOS (@remkos): to stem compiler warnings: Replace deprecated CURLINFO_CONTENT_LENGTH_DOWNLOAD #8659, Avoid warnings compiling seis #8661
  • Linux
  • Windows
• check if other GMT-derived projects work well
  • MB-System (@PaulWessel)
  • GMTSAR (@PaulWessel)
  • GMT.jl (@joa-quim)
  • PyGMT (@leouieda, @seisman, @weiji14, @maxrjones)
  • gmtmex (@PaulWessel, @joa-quim)
• reserve a DOI on zenodo (@PaulWessel, @seisman)
• run admin/gs_check.sh to test if latest ghostscript version works
• update changelog
• update the version information in CITATION.cff
• check installation instructions in doc/rst/source/install.rst
• check if there are any warnings when building the documentation
• add one new entry in doc/rst/_static/version_switch.js if it's a minor release
• 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 win64 installer and portable installer (@joa-quim)
• check if the source tarballs for Linux work well (@Esteban82, @anbj)
• check if the macOS bundles work well (@seisman, @maxrjones)
• check if the Windows installers work well (volunteers needed!)
• upload source tarballs, macOS bundle, Windows installers to the GMT FTP (@PaulWessel)
• update README and VERSION files on the GMT FTP (@PaulWessel)
• 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

• 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.
  • 7 files are attached as release assets (2 source tarballs, 4 installers and 1 checksum file).
  • download the checksum file and check if the checksums are correct
  • edit the draft release, set the target to the correct tag, and publish the release
• upload the tarball to zenodo (@PaulWessel, @seisman)
• make announcements in the GMT forum
• make announcements on the GMT Instagram
• update links on the main site (Download & Documentation)
• update install instructions on the wiki if needed

After release:

• Reset for the next version
  - [ ] update GMT_PACKAGE_VERSION_* in cmake/ConfigDefault.cmake
  - [ ] comment the set (GMT_PUBLIC_RELEASE TRUE) line

3rd-party update

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

• update conda-forge feedstock (@leouieda, @seisman, @weiji14)
• update homebrew formula (@claudiodsf, @seisman)
• update macports ports (@remkos, @seisman)
• update the RPM repository (@seisman)
• update the try-gmt Jupyter lab (@weiji14, @seisman, @maxrjones)
• update winget manifest file (@seisman)

---

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

[seisman]

I just created the checklist for GMT 6.6.0 but didn't set the release date. Since GMT 6.5.0 has been released for one year, perhaps it's time to have the GMT 6.6.0 released.

What do others think about the new release?

[Esteban82]

Yes, I agree that we should make a new release soon.

[joa-quim]

I also think we should release a new version. But it would be nice if we could advertise a little the longoptions. We have them in code but no docs at all. I would like also to include the psconvert-no-file-dup brunch. I made fixes on it and now, without the /DPS_NO_DUP building option (which sets the -! option by default) it should behave exactly like the master, but more testing would be good.

And there is also an issue with MB build that @anbj has been pushing but needs action by @dwcaress in the MB cmake script.

[remkos]

Sorry that my merge of #8654 closed this. It must have been because it had the word "resolve" in the line referring to this PR. Overzealous AI at work.

[gd-a]

Concerning the embedding of GDAL in the future release, is it best to use a dev version (currently the case with windows installer) or the latest stable ?

gdalinfo --version
GDAL 3.9.0dev-bf5289c780-dirty, released 2024/01/04

[joa-quim]

Only the Win builds done by me use the GDALdev. Don't know what other GMT builds do, but I guess many will use the latest GDAL at the time of GMT compiling, which for Ubuntus may be a 1 or 2 years old GDAL.

And, BTW, latest stable GDAL is 3.10.1

[dwcaress]

Unless you require a feature only available in the dev branch, use a stable release.
Since I'm not aware of an intent to embed GDAL into the GMT codebase, I have to ask the following:
What is the motivation for embedding GDAL? Will the GDAL library be built and installed with the same naming as if it were installed from a GDAL distribution? How about the headers? How about the 21 GDAL package programs such as gdalwar, gdalinfo, etc? How will this all be handled in package managers where packages other than GMT have GDAL as a dependency?How this work for building a package that has programs linked with and using both headers and libraries from both GMT and GDAL? I'm not opposing the approach, but I would like to understand whether this would be problematic for MB-System or any other packages that integrate with GMT libraries.

[remkos]

I assume/hope that "embedding" here means requiring it for compilation, instead of having it optional, and that only executables will be built with GDAL "embedded".
I do not see the point of including GDAL as part of the GMT code.