[PROJ] mismatch between proj release tags and tarballs

[Kristian Evers]

Greg,

The one true source for PROJ(-data) packages is download.osgeo.org/proj/ <http://download.osgeo.org/proj/>. The PROJ-data
archives found there are copied from the GitHub release. That is, the files named proj-data-x.y.z.*.

The 1.2.1.tar.gz file you find in the GitHub release is basically just the repo checkout at that tag
and put in a tar.gz file. Disregard it. As far as I am aware you can’t get rid of them from the GitHub
Release page.

Regarding the version numbers in the files. Yeah, it probably is a bit sloppy. I think we’ve always
only used major and minor versions in the actual releases (also for previous iterations of the data
package in the olden days) but somehow all three numbers found their way to the HOWTORELEASE
document when we started the PROJ-data package. I guess it is more correct but since we haven’t
yet had an opportunity to patch a previous release I don’t think we particularly need the last digit…

/Kristian

> On 27 Apr 2025, at 14.46, Greg Troxel via PROJ <proj at lists.osgeo.org> wrote:
> 
> This is just a nit and not a big deal, but I noticed an odd mismatch
> between the 1.21.0 tag and the artifacts.  I would expect the 'create
> release' to have them end up the same.
>  - https://github.com/OSGeo/PROJ-data/releases
>  - see that the tag and headline is 1.21.0
>  - see that the first artifact is
>      https://github.com/OSGeo/PROJ-data/releases/download/1.21.0/proj-data-1.21.tar.gz
>    but there is also
>      https://github.com/OSGeo/PROJ-data/archive/refs/tags/1.21.0.tar.gz
> 
>  - in https://download.osgeo.org/proj/ find
>      https://download.osgeo.org/proj/proj-data-1.21.tar.gz
> 
> pkgsrc is currently pointed at download.osgeo.org.  (I think that's a
> feature, not approving of github expecting the world to deal with their
> way and have a forge-specific fetch procedure with URLs that are not
> trivially machine-generatable from the version, with varying earlier
> parts, instead of following traditional norms of a download dir.)
> But, the file naming in github and the release page appears consistent.
> 
> I don't remember encountering this before, but looking at the release
> page on github it maybe started with 1.17.0.
> 
> I see in the release action on line 42 that only N.N.N releases are
> considered final, when that regexp probably should accept N.N also,
> intenndig to omit alpha/beta/rc.  Also that only N.N.N and N.N.NRCN are
> used for release action runs.
> 
> That's all fine, but it would seem that 1.21.0 should have tarballs that
> are named 1.21.0.  (And, unpack to 1.21.0, except that proj-data is
> unusual in that it doesn't have such a directory in the unpack.)
> 
> 
> I see that this arises in CMakeLists where there is:
> 
> set(PROJ_DATA_VERSION_MAJOR 1)
> set(PROJ_DATA_VERSION_MINOR 21)
> set(CPACK_SOURCE_PACKAGE_FILE_NAME "proj-data-${PROJ_DATA_VERSION_MAJOR}.${PROJ_DATA_VERSION_MINOR}")
> 
> but no micro.  So I guess the bug is that either there are micro
> versions or there aren't, and if so MICRO should be added to CMakeLists
> and if not the tag form in the release action and the tags used should
> drop the micro.
> 
> 
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20250427/0960b98c/attachment.htm>