Closed seisman closed 4 years ago
Following our latest contributor chat, we agreed on periodic releases, twice a year, and we probably wanted to release them not the week before AGU, despite the historical precedence of doing that numerous times in the olden days... Since 6.1 is way overdue and has lots of new stuff, it is probably fine to aim for June 1 as a firm release date and then we start the 6-month cycle on Oct 1, 2020, followed by April and October releases in future years. We will push the 3-D grid implementation to the October release.
June 1 is coming up. We need to make decision on whether or not some planned features shall go in now or be saved for 6.2:
- GMT themes. The mechanism is implemented and works well. Defining what modern mode (and others) contain is not completed. Relatively easy to pick some defaults; more work if we want to add some auto-scaling.
I prefer to save it for 6.2 so that we have more time to test and tweak the settings for each theme.
- Let -o take scales, offets, etc. Seems straightforward, but probably not essential for 6.1
6.1 if it doesn't take much time to implement it.
- What else? Any lingering issues or PRs we want to finish. 10 days is short.
We have a 6.1.0 milestone. Most of the issues in the 6.1.0 milestone are to improve the documentation, but it's OK to save most of them for 6.1.1 or 6.2.0.
IMHO, these issues should be addressed before the 6.1.0 release:
Thought in pushing #3287 but it really opens a can of works. We really should stop treating images as if they were grids and use GDAL to re-interpolate them.
Given it is June 28 and no clear path to complete an agreeable themes roll-out and suitable period of testing, I think we will wait with themes until a later release when it can be more prepared. Thus, once #3550 can be merged I think we should build GMT 6.1.0rc1 immediately.
When does SOVERSION change? Only when doing 7?
Will be off the grid this morning (HI time) but back in afternoon. We need to make progress on the check-boxes. WIth GDAL 3.1.0 I think tests are OK.no @seisman? I checked the INSTALL.md since we did that yesterday.
My internet decided to go with GDAL 3.1.1 and is permanently crashing. Already contacted technical assistance but nothing improved. In this moment I'm using the phone hotspot. We have the GEOS PR to solve. No problems with it but the CI is failing because the wrong lib is being detected (explained that in the issue)
When does SOVERSION change? Only when doing 7?
Yes, I think so. Currently, the library version is the same as the GMT version, i.e., libgmt.6.1.0.dylib.
WIth GDAL 3.1.0 I think tests are OK.
Yes.
Can I check to box that says "freeze codes and commit all changes to GitHub" above, @joa-quim and @seisman ?
gmtmex/WL_example_3.sh still fails, but I'm OK to put it after 6.1.0 release.
Let me have a look one last time. There are two issues:
It would be very good if we could do everything tonight. I'm at Lisbon with good connection but tomorrow I'll be back home where internet became shit and technician will go only Tuesday.
OK, still compiling - will take hours. But we can go ahead and assume all is well and built tarballs. Let me get that going.
OK, @GenericMappingTools/core all built and placed in ftp.soest.hawaii.edu/pwessel/release as usual.
992eb6e3e42032cf0fe5259f65ca6a8bca37e400ae49896f62dbbc5b8b9064eb gmt-6.1.0-darwin-x86_64.dmg
5cc6c38848079b9df3c94ecb53a5d2a4a685775f51e7a884aa5807b7f6fdfd6f gmt-6.1.0-src.tar.gz
ad02780153c53a1116ae0cc7945b6f533f066af44c30d7f95ff138cfede1867c gmt-6.1.0-src.tar.xz
I will try a src and bundle later but after family zoom. The gdal build finished so there is taht. But I suggest you build win installers with the current src tar.
Tested in a clean Windows VM
http://joa-quim.pt/mirone/gmt-6.1.0-win64.exe http://joa-quim.pt/mirone/gmt-6.1.0-win32.exe
6.1.0 64-bit happily made me a pdf and a png. PDF opened in edge browser, and png opened in Photos. Trying 32 next.
32 seems fine too. Great, now trying the bundle. Note, I typed ffmpeg to check if in the path so things are there but I did not try to make a movie or something complicated.
This PR installs GMT 6.1.0 on macOS and Windows (both win32 and win64) using the Azure Pipelines VMs, and runs several gmt commands. All look good to me.
Ah, I forgot to mention. The gmt-6.1.0-src.tar.xz
lacks the admin
directory. Had to copy it from master.
I thought nobody but us needs it, no?
But no secrets in there so we could add it.
macos Bundle seems OK, made a coast plot and the globe.sh movie. Building from source on Linux remains.
The admin
dir is needed to build the installers and has the License files.
@dongdong, looks like we should include admin in the tarball after all?
Only you and @joa-quim need the admin
directory. Other users can still create non-portable installers without it.
I am having some issues with my dual-boot WIn/CentOS - might you be able to give the tarball a minimal testing? Then we can proceed down the check list.
OK. Will let you in a few minutes.
GMT ftp has 5.4.5, 6.0.0rc5, and 6.0.0. Any reason not to remove rc5? I will leave the rest of course.
Just remove rc5.
The tarball is OK on CentOS 8.
Just noticed new tar gz is 64 Mb old is 79Mb. Is this just PNG quant or did we miss something? Documentation (again)?
Yes, the doc_release/html/_images
directory is 18Mb in GMT 6.1.0, but 33 Mb in GMT 6.0.0.
Good job, @seisman!.
The total size of the 50 examples is ~19 Mb in GMT 6.0.0. Now we have 52 examples but only ~9.4 Mb. All the images still keep high-quality.
OK, worked my way down the list. Not sure about the GitHub Release - probably you can check that. And perhaps you can make the 6.1 branch so we know it is done right. I can then merge the bug fix PR into 6.1 branch (and I guess we periodically will merge 6.1 into master).
I'll update the links on the main site.
Unresolved issues - possibly items for checklist:
We should ensure that both MB-System and GMTSAR can work with a new release before we release. I know they should have a system in place to check as well, but they don't. I will build both here locally and I am pretty sure we are OK, but will see.
Yes, also add PyGMT and GMT.jl to the checklist.
I updated the main site in this PR. A problem is, the link for the GMT 6.1.0 documentation is not available.
From what I understand, after pushing new commits to the 6.1 branch, it will create the 6.1 documentation automatically.
And I think I made a change in 6.1 to the function gmt_get_palette which now is
gmt_prototypes.h:EXTERN_MSC struct GMT_PALETTE gmt_get_palette (struct GMT_CTRL GMT, char *file, enum GMT_enum_cpt mode, double zmin, double zmax, double dz);
Unfortulately, MB-system uses a macro we made (gmt_get_cpt) to call that function:
but now it should only have 6 args, not 7 [this has to do with upgrades to remote files and CPTs).
So I can tell Dave that he probably should tell people that his 5.7.5 requires 6.0.0 and then release a 5.7.6 after using gmt_get_pallete directly and do the other things the gmt_mb.h is helping him with for now.
I guess I will add a PR to 6.1 that updates gmt_mb.h for now?
I guess I will add a PR to 6.1 that updates gmt_mb.h for now?
Need to finish the checklist first, i.e., update the GMTVERSION* and set GMT_PUBLIC_RELEASE to false.
GMTSAR compiles and links fine with master.
Wait for 6.1 docs to be built before posting a forum message and website news item with link to it, I think. Do you know when it runs?
It should be ready in half an hour.
I see master 6.2 has refreshed so I guess it is still working on 6.1. I have drafted a news and will insert a link to our ChangeLog as well as website. Then, with the forum link I will do the reverse from the website.
Dinner with a guest is starting here so may be a bit slow for some hours...
Now https://docs.generic-mapping-tools.org/6.1/ and https://docs.generic-mapping-tools.org/latest/ are the 6.1.0 documentation.
Should I use the link to the dev/ doc for the datasets - when that rebuilds it will list the earth ages. 6.1 has the rest minus earth ages.
Version: 6.1.0 Scheduled date: July 1, 2020
Before release:
src/gmt_make_*.sh
to update some .c and .h filesadmin/gs_check.sh
to test if latest ghostscript version workscmake/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:
After release:
GMT_PACKAGE_VERSION_*
incmake/ConfigDefault.cmake
set (GMT_PUBLIC_RELEASE TRUE)
line3rd-party update