<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Greg,<div><br></div><div>The one true source for PROJ(-data) packages is <a href="http://download.osgeo.org/proj/">download.osgeo.org/proj/</a>. The PROJ-data</div><div>archives found there are copied from the GitHub release. That is, the files named proj-data-x.y.z.*.</div><div><br></div><div>The 1.2.1.tar.gz file you find in the GitHub release is basically just the repo checkout at that tag</div><div>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</div><div>Release page.</div><div><br></div><div>Regarding the version numbers in the files. Yeah, it probably is a bit sloppy. I think we’ve always</div><div>only used major and minor versions in the actual releases (also for previous iterations of the data</div><div>package in the olden days) but somehow all three numbers found their way to the HOWTORELEASE</div><div>document when we started the PROJ-data package. I guess it is more correct but since we haven’t</div><div>yet had an opportunity to patch a previous release I don’t think we particularly need the last digit…</div><div><br></div><div>/Kristian<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 27 Apr 2025, at 14.46, Greg Troxel via PROJ <proj@lists.osgeo.org> wrote:</div><br class="Apple-interchange-newline"><div><div>This is just a nit and not a big deal, but I noticed an odd mismatch<br>between the 1.21.0 tag and the artifacts. I would expect the 'create<br>release' to have them end up the same.<br> - https://github.com/OSGeo/PROJ-data/releases<br> - see that the tag and headline is 1.21.0<br> - see that the first artifact is<br> https://github.com/OSGeo/PROJ-data/releases/download/1.21.0/proj-data-1.21.tar.gz<br> but there is also<br> https://github.com/OSGeo/PROJ-data/archive/refs/tags/1.21.0.tar.gz<br><br> - in https://download.osgeo.org/proj/ find<br> https://download.osgeo.org/proj/proj-data-1.21.tar.gz<br><br>pkgsrc is currently pointed at download.osgeo.org. (I think that's a<br>feature, not approving of github expecting the world to deal with their<br>way and have a forge-specific fetch procedure with URLs that are not<br>trivially machine-generatable from the version, with varying earlier<br>parts, instead of following traditional norms of a download dir.)<br>But, the file naming in github and the release page appears consistent.<br><br>I don't remember encountering this before, but looking at the release<br>page on github it maybe started with 1.17.0.<br><br>I see in the release action on line 42 that only N.N.N releases are<br>considered final, when that regexp probably should accept N.N also,<br>intenndig to omit alpha/beta/rc. Also that only N.N.N and N.N.NRCN are<br>used for release action runs.<br><br>That's all fine, but it would seem that 1.21.0 should have tarballs that<br>are named 1.21.0. (And, unpack to 1.21.0, except that proj-data is<br>unusual in that it doesn't have such a directory in the unpack.)<br><br><br>I see that this arises in CMakeLists where there is:<br><br>set(PROJ_DATA_VERSION_MAJOR 1)<br>set(PROJ_DATA_VERSION_MINOR 21)<br>set(CPACK_SOURCE_PACKAGE_FILE_NAME "proj-data-${PROJ_DATA_VERSION_MAJOR}.${PROJ_DATA_VERSION_MINOR}")<br><br>but no micro. So I guess the bug is that either there are micro<br>versions or there aren't, and if so MICRO should be added to CMakeLists<br>and if not the tag form in the release action and the tags used should<br>drop the micro.<br><br><br>_______________________________________________<br>PROJ mailing list<br>PROJ@lists.osgeo.org<br>https://lists.osgeo.org/mailman/listinfo/proj<br></div></div></blockquote></div><br></div></body></html>