-
Notifications
You must be signed in to change notification settings - Fork 348
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
Release GMT 6.2.0rc2 #5191
Comments
Are there any outstanding issues that need to be addressed before rc2, @PaulWessel? |
Why will there be an RC2? We are not even respecting RC1. |
What do you mean we are not respecting RC1? |
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. |
#5124 for example touched quite a bit of code. |
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. |
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.? |
They are triggered on any PRs that change |
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. |
All clear, but I've not tried MB. Too risky. |
Looks good for PyGMT. |
Any schedule for the rc2 release? |
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. |
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. |
It is tricky but I will need to reproduce the problem and it seems I cannot do so on macOS. |
Hi @joa-quim please check the GMT.jl box above if passes your tests. |
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? |
Issue solved. It was a trick regression that failed in my computer but passed in the CI tests. |
Great. Are you really gonna make me check that box or will you? |
macOS tarballs and bundle are at ftp.soest.hawaii.edu:https://gmtrelease for testing:
|
Hi @joa-quim hoping you can build the win installer. |
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. |
@joa-quim, can you please post the sha256sum for the win64 installer? |
SHA1 hash of .\gmt-6.2.0rc2-win64.exe: |
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 ? |
The version-independent share directory is |
Thanks, /opt/homebrew/share/proj worked. |
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 |
Does the M1 bundle build work with Julia? (the Intel doesn't because of the dependencies name screwing mess). Setting the right |
Slow this morning. Just installing julia on the laptop now and will see. |
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:
Of course, there is no newer version of macOS. This has to do with MacPorts yelling stupidity like this:
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. |
Yes, it is annoying. |
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. |
Finally got Xcode 12.5 installed, updated MacPorts to 2.7, and more importantly added
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. |
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? |
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... |
I guess we'll have to wait. The curiosity was to see if the ARM bundle works where the Intel one fails. |
Yes, and Matlab 2021a is still Intel only so no point testing mex yet either. |
Would this impact the use of the binaries on older macOS's? |
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 |
I have no idea. |
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. |
The test passed. Updated shasums:
|
Is there any more that needs to be done for the arm bundle or should we move onwards? |
No, I think that is all, thanks. Good to release I think; the WIPs are piling up... |
OK, I will complete the next items. |
Draft release is here: https://github.com/GenericMappingTools/gmt/releases |
Looks good to me. |
Finally done unless we want to clean up the |
Version: 6.2.0rc2
Scheduled date: May 24, 2021
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_PACKAGE_VERSION_SUFFIX
to rcxGMT_PUBLIC_RELEASE
toTRUE
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_SUFFIX
line 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: