A packaging fix. AppGeek itself is unchanged from 1.0.1 - no new features, no behaviour changes.
What was wrong
The binaries published with 1.0.1 were stamped with the wrong version number. Right-clicking AppGeekSetup.exe and looking at Properties > Details showed 1.0.0, even though the release was 1.0.1.
The build never received the version. Both the project file and the installer script carried a hardcoded 1.0.0, and nothing passed the tag's version in, so every build produced files labelled 1.0.0 regardless of what was being released.
What changed
The release build now takes its version from the tag and writes it into all three executables. A check step reads the version back out of each finished file and fails the build rather than publishing if any of them disagrees - so a mislabelled download cannot ship again without someone noticing.
Which file do I want?
| File | Who it is for |
|---|---|
AppGeekSetup.exe |
Most people. Installs to Program Files, Start menu entry, proper uninstall entry |
AppGeek.exe |
Portable. Self-contained, nothing to install first |
AppGeek-light.exe |
Portable, and you already have the .NET 8 Desktop Runtime |
Verifying your download
SHA256SUMS.txt is published below.
Get-FileHash .\AppGeekSetup.exe -Algorithm SHA256
The binaries are not code signed, so Windows SmartScreen warns on first run - click More info, then Run anyway.
You can also now confirm the version yourself before installing: right-click the file, Properties > Details. It should read 1.0.2.
What's Changed
- Cover winget version parsing with tests (APP-03) by @techygeekshome in #1
- README: document the one network call (APP-09) by @techygeekshome in #2
- Stamp the release version into the built binaries by @techygeekshome in #3
- Bump to 1.0.2 so the next release ships correctly stamped binaries by @techygeekshome in #4
New Contributors
- @techygeekshome made their first contribution in #1
Full Changelog: v1.0.1...v1.0.2
