Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Release GMT 6.2.0rc2 #5191

Closed
37 of 38 tasks
maxrjones opened this issue May 3, 2021 · 57 comments
Closed
37 of 38 tasks

Release GMT 6.2.0rc2 #5191

maxrjones opened this issue May 3, 2021 · 57 comments
Milestone
6.2.0

Comments

@maxrjones
Copy link
Member

maxrjones commented May 3, 2021 •
edited
Loading

Version: 6.2.0rc2

Scheduled date: May 24, 2021

Before release:

  • check if all tests pass on macOS, Linux and Windows
  • check if other GMT-derived projects work well
  • run src/gmt_make_*.sh to update some .c and .h files
  • run admin/gs_check.sh to test if latest ghostscript version works
  • update changelog
  • check installation instructions in INSTALL.md
  • 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_PACKAGE_VERSION_SUFFIX to rcx
    • set GMT_PUBLIC_RELEASE to TRUE
  • freeze codes and commit all changes to GitHub

Release:

  • create source tarballs (tar.gz and tar.xz) (@PaulWessel)
  • create macOS bundle (@PaulWessel)
  • create Windows installers (win64) (@joa-quim)
  • check if the source tarballs, macOS bundle and Windows installers work well
  • upload source tarballs, macOS bundle, Windows installers to 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.
    • 6 files are attached as release assets (2 source tarballs, 3 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
  • make announcements in the GMT forum
  • make announcements on the GMT twitter
  • update links on the main site (News, Download & Documentation)

After release:

  • comment the GMT_PACKAGE_VERSION_SUFFIX line in cmake/ConfigDefault.cmake
  • comment the set (GMT_PUBLIC_RELEASE TRUE) line
  • 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.

  • Party 🎉 (don't tick before all other checkboxes are ticked!)
@maxrjones
Copy link
Member Author

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

@joa-quim
Copy link
Member

joa-quim commented May 3, 2021

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

@maxrjones
Copy link
Member Author

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

What do you mean we are not respecting RC1?

@joa-quim
Copy link
Member

joa-quim commented May 3, 2021

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
Copy link
Member Author

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., #5170, #5178, and #5181), which were the motivation for an RC2.

@joa-quim
Copy link
Member

joa-quim commented May 3, 2021

#5124 for example touched quite a bit of code.

@PaulWessel
Copy link
Member

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.

@maxrjones maxrjones pinned this issue May 5, 2021
@PaulWessel
Copy link
Member

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
Copy link
Member Author

maxrjones commented May 8, 2021 •
edited
Loading

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 (#5193), so I will check the box.

@PaulWessel
Copy link
Member

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
Copy link
Member

joa-quim commented May 8, 2021

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

@seisman
Copy link
Member

seisman commented May 8, 2021

Looks good for PyGMT.

@weiji14 weiji14 mentioned this issue May 10, 2021
Open
@seisman
Copy link
Member

seisman commented May 13, 2021

Any schedule for the rc2 release?

@PaulWessel
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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

@PaulWessel
Copy link
Member

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

@PaulWessel
Copy link
Member

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
Copy link
Member

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

@PaulWessel
Copy link
Member

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

This was referenced May 20, 2021
Merged
Merged
@maxrjones
Copy link
Member Author

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
Copy link
Member

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

@joa-quim
Copy link
Member

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

@PaulWessel
Copy link
Member

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
Copy link
Member Author

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

@joa-quim
Copy link
Member

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

@PaulWessel
Copy link
Member

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
Copy link
Member

seisman commented May 21, 2021

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
Copy link
Member

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

@PaulWessel
Copy link
Member

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
Copy link
Member

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.

@seisman seisman added this to the 6.2.0 milestone May 22, 2021
@PaulWessel
Copy link
Member

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

@PaulWessel
Copy link
Member

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
Copy link
Member Author

Yes, it is annoying.

@PaulWessel
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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

@PaulWessel
Copy link
Member

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

@maxrjones
Copy link
Member Author

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
Copy link
Member

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

@maxrjones
Copy link
Member Author

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
Copy link
Member

seisman commented May 24, 2021

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
Copy link
Member

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.

@maxrjones
Copy link
Member Author

The test passed. Updated shasums:

b4fb5f79b2a9f8b7187a20200ecfb418c533d970ed36f5e8cece73ad630e2176  gmt-6.2.0rc2-darwin-x86_64.dmg
913a80bc6c1768b6728bd256745dd3aa16fe08f20c04bb7d322aa4a2ba8a6423  gmt-6.2.0rc2-src.tar.gz
0fced6881fd16bda1ba6334003153e0f3afa169820450dfbbd23b7960b864b47  gmt-6.2.0rc2-src.tar.xz

@maxrjones
Copy link
Member Author

Is there any more that needs to be done for the arm bundle or should we move onwards?

@PaulWessel
Copy link
Member

No, I think that is all, thanks. Good to release I think; the WIPs are piling up...

@maxrjones
Copy link
Member Author

No, I think that is all, thanks. Good to release I think; the WIPs are piling up...

OK, I will complete the next items.

@weiji14 weiji14 mentioned this issue May 24, 2021
Merged
7 tasks
@maxrjones
Copy link
Member Author

Draft release is here: https://github.com/GenericMappingTools/gmt/releases
Please provide any comments. I'll publish the release shortly if there are none.

@PaulWessel
Copy link
Member

Looks good to me.

@maxrjones
Copy link
Member Author

Finally done unless we want to clean up the gh-pages branch (see #5259)

@maxrjones maxrjones unpinned this issue May 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
6.2.0
Development

No branches or pull requests
4 participants
@joa-quim @seisman @maxrjones @PaulWessel