[PROJ] Motion: adopt RFC 5
Even Rouault
even.rouault at spatialys.com
Wed Jan 29 05:11:02 PST 2020
Kristian,
>(I guess we will call that proj-data-1.0?)
Just changed to that
> but how is that archive produced? Similar to the old grid
> packages, e.g.
> mkdir build
> cd build
> cmake ..
> make dist
You guessed correctly !
> Would be nice to have a HOWTORELEASE file to capture this knowledge.
Sure, proposed one in https://github.com/OSGeo/PROJ-data/pull/8
>
> Does the release procedure also require as CDN sync or is that done when
> new files are registered?
I've added in the above HOWTO-RELEASE a step for that. But I'd expect the
sync_to_cdn.sh script to be run more regularly, once a new grid has been
merged into PROJ-data & registered in proj.db, so that users tracking PROJ
master & using network capabilities can immediately use it.
We could probably run it automatically through Travis or a GitHub action once
a PR is merged, but for now, I think it's probably best if you keep manual
control on when we resync the CDN. This allows to do manual testing after
merging a PR & before resynchronizing the CDN.
One thing I didn't mention is that pull requests submitted to PROJ-data run a
few sanity checks by
https://github.com/OSGeo/PROJ-data/blob/master/travis/check_new_grids.sh (run
by .travis.yml)
New or modified TIFF grids are first submitted to gdalinfo, so one can see the
output in the Travis log
And the check_gtiff_grid.py script is run on them. If errors are found, then
the Travis build fail. Warnings or information are displayed in the log, but
do not fail the build.
See https://travis-ci.org/rouault/PROJ-data-tmp/builds/643019546 for a
simulation I did with a test repository
Bottom line is to look at the Travis logs to have a first outlook of what is
being submitted.
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
More information about the PROJ
mailing list