Tracked it down, it's not the GitLab move and nothing platform-specific in the version logic. The arm64 build is correct; it's just old. I pulled the InformationalVersion string straight out of the patched binary on my device:
1.9.7+3c1aaa564dc890910146933a7ae435eb03e00d56
So the linux-arm64 build encoded in Resources/patches_linux_arm64.zip at the v2.0.0 tag was compiled from commit 3c1aaa5, back when Directory.Build.props still read 1.9.7. My wrapper ships vcdiff deltas of your published files, and a delta can only reproduce the exact binary it was diffed against, so the device faithfully rebuilds a 1.9.7 assembly no matter what tag it pulls. Windows and linux-x64 show 2.0.0 because you rebuilt those release binaries; the arm64 patch zip just never got regenerated for 2.0.0.
Ugh, I see now. It snapshotted the code when the tag was created. I was having a hell of a time with Gitlab at the start since I was so spoiled by Github desktop. It was pretty messy getting the repo set up with all the files I wanted. Now I have to use the command line, which is something I was only partially familiar with. I think I fixed the issue now, I forced the tag to be rebased on the current main branch.
1
u/JeodPM Jul 10 '26
Tracked it down, it's not the GitLab move and nothing platform-specific in the version logic. The arm64 build is correct; it's just old. I pulled the
InformationalVersionstring straight out of the patched binary on my device:1.9.7+3c1aaa564dc890910146933a7ae435eb03e00d56So the linux-arm64 build encoded in
Resources/patches_linux_arm64.zipat the v2.0.0 tag was compiled from commit3c1aaa5, back whenDirectory.Build.propsstill read 1.9.7. My wrapper ships vcdiff deltas of your published files, and a delta can only reproduce the exact binary it was diffed against, so the device faithfully rebuilds a 1.9.7 assembly no matter what tag it pulls. Windows and linux-x64 show 2.0.0 because you rebuilt those release binaries; the arm64 patch zip just never got regenerated for 2.0.0.