New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect version information applied to Windows releases #7441
Comments
Previous way of addressing compiled .rc files led to stale intermediate targets leading to issue #7441
Previous way of addressing compiled .rc files led to stale intermediate targets leading to issue #7441
1.17.14 Windows executables are showing the correct information in the version now. Thanks. Awaiting the next 1.16 release before closing. Edit: File version is 1.17.14.0, but Product version is 1.17.13+dev. The former is what shows in the on-hover tool-tip so it's probably fine - and I've never understood why Microsoft requires two different versions - but I wonder if the latter should be 1.17.14.0 as well. |
1.16.9 release now reports 1.16.9.0 for file version, 1.16.8+dev for product version. |
I'm re-opening this. 1.17.18 release, downloaded from sourceforge.net, has 'File version' reported as 1.17.15.0 and 'Product version' reported as 1.17.15. Why does this happen? As an aside, the original report shows 'Copyright' as 2003-2018 and 1.17.18 release has 'Copyright' as 2003-2022. Still not quite right, although an improvement over the older releases. |
@loonycyborg looks like 9df0a59 was not enough. The copyright can be adjusted in |
That happens mostly because that file is in packaging/windows, I tried making all builds out-of-tree but it seems something still makes file wesnoth.o in original dir and new builds will prefer original tree one despite it being old one. |
In fact it's all because of confusion caused by packaging/windows symlink, I need to think how to reorganize this build step to avoid this. |
they were created there via symlink which confused subsequent builds leading to issue #7441
Windows 1.17.19 release:
Seems good for now, so closing. Thanks. |
Because 1.17 was working (and I just confirmed 1.17.20 follows the same - correct - pattern as 1.17.19), I'd neglected to check 1.16 releases. I'm not sure if the change for master also needs to be applied for 1.16. Despite what the details say, this is the properties listing for Wesnoth 1.16.10 official Windows release (note the date modified), 1.16.9 was released in April 2023. |
Is this fixed now? |
Need to wait for 1.16.11 release. |
Looks good for at least the Steam release executable. Thanks. |
Game and System Information
Description of the bug
1.16.8 release downloaded via Steam:
1.17.13 release downloaded from sourceforge.net:
I suppose this is low priority, but it causes confusion when encountering problems like in #7438.
Steps to reproduce the behavior
Check the version information in Properties -> Details (or simply wait for tool-tip pop-up with the same information in Windows Explorer).
Expected behavior
Version information should match the actual release version.
Additional context
No response
The text was updated successfully, but these errors were encountered: