Release GMT 6.7.1

[seisman]

Version: 6.7.1

Scheduled date: XXX XX, 20XX

Before release:

• check if there are new SCM releases
• check if all tests pass on
  • macOS (after incorporating nswing.c: avoid numerous compilation warnings #9203)
  • Linux
  • Windows
• check if other GMT-derived projects work well
  • MB-System
  • GMTSAR
  • GMT.jl (@joa-quim)
  • PyGMT (@seisman, @weiji14, @maxrjones)
  • gmtmex (@joa-quim)
• reserve a DOI on zenodo (@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:

• Make sure that "set (DO_TESTS ON)" and "set (DO_SUPPLEMENT_TESTS ON)" Are commented in ConfigUser.cmake
• create source tarballs (tar.gz and tar.xz)
  This is done by admin/build-release.sh, and is executed by:
  cmake --build . --target gmt_release plus cmake --build . --target gmt_release_tar
• create Windows win64 installer and portable installer (@joa-quim)
• check if the source tarballs for Linux work well (@Esteban82, @anbj)
• check if the Windows installers work well (volunteers needed!)
• make a tag and push it to github (Must replace the old FTP with a place to upload packages)

  # 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 (FAILS WHILE FTP IS NOT REPLACED).
  We need to go to the GitHub Release page, and review it manually.
  • 5 files are attached as release assets (2 source tarballs, 2 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 (@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]

PR #9177 fixes a critical bug in meca that PR #8966 recently introduced (first appears in GMT 6.7.0), so we need a new release.

Considering that there have been 68 commits since 6.7.0, I think we have two options:

• Release GMT 6.8.0 with all the changes/commits included
• Release GMT 6.7.1 with only a few critical commits included (e.g., meca: Only stretch master CPTs given in -C to the depth range #9177, Limit the compilation of gmt_update to MSVC only #9121, Limit the compilation of gmt_update to MSVC only #9121).

[Esteban82]

I don't have a very strong opinion. But I'm leaning toward the release of version 6.7.1.

[remkos]

I agree.

[seisman]

I've created the 6.7 branch and backported a few commits into it. See 6.7.0...6.7 for the changes compared to the 6.7.0 release. Let me know if you think any more commits should be backported.

[joa-quim]

Well, I think basically all commits done so far should go into 6.7.1

[seisman]

There are commits that add new features (e.g., #9199, #9206), so strictly speaking, they can't be in 6.7.1.

[joa-quim]

If we want to be that strict (and I must remember that we never really followed the SEMVER otherwise we would still be in GMT4.XXX) than we must go to 6.8.0.