Closed lmarz closed 2 years ago
Eek, @MathiasMagnus did I mess something up here?
Looks like this is driven by the project version in the CMake file, which is still the older "2022.05.18", so that's at least part of the problem. The leading zero gets removed by CMake when it parses this into the PROJECT_VERSION variable.
Should we try to make the directory in the zip and tgz files match the git tag? Or would it be OK to remove the directory altogether, since the git tag is in the filename anyhow?
I think we didn't bump the version inside CMakeLists.txt
. Last time we did this as two separate commits.
I didn't know we'll be tagging right after the submodule bump. Anyhow, I'll update RELEASE.md
to make sure we don't go astray next time. Overwriting the version tag should trigger the release scripts again.
As for the 0 being swallowed from 05, that should not happen. I've already seen that issue while working on the CD scripts and I recall solving that. On the CLI the package is renamed to holding the Git tag name verbatim. And I think I did something on the CMake side as well, but I may be wrong. Revisiting...
Reopening until we do a release with the corrected naming.
Hi - can you please confirm that the latest release (v2022.09.30) fixed the naming issue? Thanks!
Yes, the version number now matches up everywhere. Thank you very much
In the newest release, the downloadable source file OpenCL-SDK-v2022.09.23-Source.tar.gz has the directory OpenCL-SDK-2022.5.18-Source. Not only do the dates not match up, but the version string of the directory doesn't contain a 0 in the first space, when the day or the month is less than 10.
This inconsistency makes it quite hard to automate things.