-
Notifications
You must be signed in to change notification settings - Fork 384
Release GMT 6.4.0 #6772
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
What GS version will go into the release? 9.56 is out and causing a few tiny changes/annoying failures (#6598), but isn't updated on macports or ubuntu packages yet. |
I think we are stuck with 9.55.0 until macports changes. |
Do we need to change the SO_VERSION to 7 given that we added this to the API:
The CMakefile says
|
I don't think we need to bump the |
Building docs I got these warnings. ANyone able to help/address?
|
Thanks for the events help. I guess we need to live with this one for now?
|
Yes, you may be using an old version of Sphinx. |
Needless changing the SO version number is the main source of compatibility hell on unix.
|
@joa-quim , please test and if GMT.jl works with this candidate then check off above. If it is easy for you to run a basic check on gmt.mex as well then that would be great. |
Hi @meghanrjones and @seisman - the tests run fine for me locally in macos but I think one of you typically turns on full checks in the CI before we check off on the test box? |
I think all fine in MEX. Run a couple of Mirone/GMT MEX commands and no problems. |
The latest full tests (https://github.com/GenericMappingTools/gmt/actions/runs/2474641289) pass on Linux and Windows. There are four failures on macOS are due to changes in ghostscript 9.56.1 and are tracked in #6598 (comment). |
Could we use |
I don't think |
Maybe someone can create a brew tap for Ghostscript versions, like this one https://github.com/chhei/homebrew-ghostscript ? |
Given this, I have checked the "pass test" box for now. |
Please check if PyGMT is OK with this version. |
Working on it now |
The only PyGMT failures were known (GenericMappingTools/pygmt#1929), so I checked the box. |
Would it be an idea to add ‘update gmt page on wikipedia’ (https://en.m.wikipedia.org/wiki/Generic_Mapping_Tools) to the check list? Not that wikipedia is crucial, but it often is what people first meet when trying to find out more about something, e.g. gmt. |
Yes, I think that could go under the "volunteer's needed" section if you want to submit a PR with an edit to https://github.com/GenericMappingTools/gmt/blob/master/.github/ISSUE_TEMPLATE/release_checklist.md. For this release, you should have permissions to manually edit the checklist. |
Tried to build tarballs and bundle but macos certification failed, probably because certificates have expired. Awaiting feedback from UH IT. |
I have made the tar balls:
both are at I will make the bundles tomorrow as my wifi and cellular at the apartment messes with the certification (I have updated the certificates but Xcode needs to check a time-server which fails at home). But @joa-quim should be able to build from tarball. |
As usual only tested tested that they run. http://fct-gmt.ualg.pt/tmp/gmt-6.4.0-win64.exe |
@joa-quim There are two copies of README and LICENSE in the |
I have finally been able to build the macos bundles for arm and x86_64, both now on the ftp.soest.hawaii.edu/pwessel/release place:
|
Great, thanks! |
|
Trying the x86 bundle built in Hawaii on my iMap Pro here:
Plot works. GSHHS is included but there are no DCW files in the bundle... Did we change anything? |
I can see the DCW files in the ARM bundle. Weird. |
Checking the Hawaii Intel mac. I do have these set in the environment
and both directories exist and have the files. Sam as on the M1 mac. |
Cmake says
|
Building log says:
But then CPack Error: Error executing: /usr/bin/codesign --deep -f --options runtime -s "Developer ID Application: University of Hawaii (B8Y298FMLQ)" "/Users/pwessel/GMTdev/gmt-dev/build/_CPack_Packages/Darwin/Bundle/gmt-6.4.0-darwin-x86_64/GMT-6.4.0.app" so probably got an incomplete bundle. The one built on the iMac Pro (also Intel) comleted and has the files so I will update the file in release shortly. |
Updated:
This one has GSHHG and DCW. It is interesting that the ARM file is 179Mb and the Intel is 159Mb though. |
This is probably because the DCW repo has files without extensions, which Windows abhors. Leave for now, but perhaps the DCW repo should just rename those two files to end in .TXT? |
Hi @anbj and @Esteban82, might you be able to test the 6.4 tarball to make sure you can build from it? E.g. ftp.soest.hawaii.edu/pwessel/release/gmt-6.4.0-src.tar.gz |
Built and works as expected. |
I suggest we break the task that says check if the source tarballs, macOS bundle and Windows installers work well since most of us cannot check all three and we are reluctant to check to box based on testing just one. While there is no binding agreements here, perhaps we could split into three and add suggsted names like for other tasks? E.g.
I am often testing the bundle myself but I think it is best if people other than the maker of the item do the testing. |
The tarball for Linux - this is basically just checking out a given commit (which is to be released), right? Or is it more to it? (No problem testing the tarball, just curious). |
The extra DCW are probably due to me having unzipped the file into a my share folder some older ones that got renamed meanwhile stayed there too. |
Yes, I think so. For several releases now I build the installers from master while it has that commit active. |
Well, I think the test is to actually take the tarball since if we have screwed up then master will not be the same as a crippled tarball, so best to actually download the tarball and build from it to detect any problems, |
I think it's best to use https://github.com/GenericMappingTools/gmt-release-testbot if possible. Testing in the CI is less likely to be impacted by local configuration nuances. |
Agreed, even better. So we need a CI script we can trigger to install the bundle and then run said test script? |
https://github.com/GenericMappingTools/gmt-release-testbot/pull/33/files is an example of how to test the pre-released files. I can set this up manually this evening. |
@joa-quim, might there be a time when we can drop the 32 vs 64 and just release the 64-bit installer? Are there 32-bit Windows computers in the wild still? Asking for a friend. |
Might we check the box on testing and move into releasing today? I know the macos bundle runs (perhaps requires latest OS) and linux can build from the tarball. have anyone tried the windows installers ? I used to at least run the installer and try a coast command but my Win laptop is in Hawaii. |
I tested the installers to see if they run. |
OK, I have checked the box and will place 6.4 on the GMT ftp server etc. |
Hopefully @meghanrjones or @leouieda can do the Twitter item and @Esteban82 the Instagram posting now. |
I just post it on Instagram. |
Submitted PR for macports update of gmt6 port: macports/macports-ports#15164 |
Uh oh!
There was an error while loading. Please reload this page.
Version: 6.4.0
Scheduled date: June 17, 2022
Remaining issues (add any blocking issues/PRs here):
Before release:
src/gmt_make_*.sh
to update some .c and .h filesadmin/gs_check.sh
to test if latest ghostscript version worksdoc/rst/_static/version_switch.js
if it's a minor releasecmake/ConfigDefault.cmake
GMT_VERSION_YEAR
is current yearGMT_PACKAGE_VERSION_*
is correctly setGMT_LIB_SOVERSION
is correctly setGMT_PUBLIC_RELEASE
toTRUE
GMT_VERSION_DOI
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.
After release:
GMT_PACKAGE_VERSION_*
incmake/ConfigDefault.cmake
set (GMT_PUBLIC_RELEASE TRUE)
line3rd-party update
Volunteers needed! Please let us know if you volunteer to help to maintain GMT in these 3rd-party tools.
The text was updated successfully, but these errors were encountered: