fix (windows) removed NSIS semver build version numeric only validation

[unknovvn]

Closes #8038

[github-actions]

Package Changes Through 861c350

There are 3 changes which include tauri-bundler with patch, tauri-cli with patch, @tauri-apps/cli with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
tauri-bundler	2.2.2	2.2.3
@tauri-apps/cli	2.2.5	2.2.6
tauri-cli	2.2.5	2.2.6

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[FabianLars]

your first change file was correct. the bot sends the link to create a new one unconditionally at the moment :/

[unknovvn]

@FabianLars haha, it got me. Gonna remove the bot generated file then. Thanks 🙇

[FabianLars]

Okay so i just checked again and this won't work. VIProductVersion and VIFileVersion must be numeric only in a X.X.X.X format. This is a requirement by NSIS which if i got that right is because those values are used to set https://learn.microsoft.com/de-de/windows/win32/api/verrsrc/ns-verrsrc-vs_fixedfileinfo?redirectedfrom=MSDN which also requires numeric-only values.

I'm not sure what VS_FixedFileInfo is actually used for though because for example the versions in the file properties' Details tab are set via VIAddVersionKey.

We could modify the check to replace the build/pre data with .0 if it's non-numeric, keeping the "normal" version for VIAddVersionKey and to then wait and see if anything breaks.

[unknovvn]

I have additionally researched this topic a bit more and it looks like @FabianLars is correct - NSIS VIProductVersion requires all 4 parts to be numbers.
Personally I think that replacing build version with .0 if it's non-numeric is not correct as it's better to throw a build error and indicate that this format is not supported rather than introducing unexpected behavior.

One thing I noticed, that msi convert_version method has additional validation regarding correctness of each version part. Which might be added to nsis in order to unify this behavior.

[FabianLars]

Personally I think that replacing build version with .0 if it's non-numeric is not correct as it's better to throw a build error and indicate that this format is not supported rather than introducing unexpected behavior.

Yeah, fair. I'm just thinking about how to expose VIAddVersionKey to devs, which supports non-numeric versions, without adding yet another version config.

[unknovvn]

If we would decide to expose build version with non-numeric values as a VIAddVersionKey to devs - it would require interpreting VIProductVersion in some way. Either to add .0 at the end (which would replicate default NSIS behavior) or to add stripped out version of non-numeric build version (remove non-numeric values from the build version). In both cases this would introduce unexpected behavior

[unknovvn]

Although after checking initial Bug it looks like author of that ticket was expecting that file version would have default .0 revision value instead of non-numeric build version value (probably expecting same behavior for VIProductVersion). In that case it looks like for non-numeric build numbers we could set VIProductVersion and FileVersion with values where non-numeric build version would be replaced by .0 and for product version it would return original build version

[unknovvn]

@FabianLars please verify if my assumptions are correct and this PR can be merged. 🙇

[FabianLars]

In both cases this would introduce unexpected behavior

The question would be where? Where is VIProductVersion used that this would cause issues. The only thing i can think of that we have to check is updating == installing 1.0.0-builld.20 when 1.0.0-beta.1 is already installed on the system.

Tauri's update can handle that fine but the installers, or at least the wix installer have built-in checks for this as well, not sure how our nsis installer behaves.

[FabianLars]

This needs to be reverted.

1. FileVersion and ProductVersion should show the same value and both should support semver.
   • Talking about the VIAddVersionKey variant, not VIProductVersion/VIFileVersion !
2. We use VERSION a few more times in this file where it expects the full semver.

VIProductVersion should be the only thing that gets a modified version.

So i think the approach in general (for the other files as well) would be:

1. Set VERSION with the user specified version without modifications
2. Try to use the user specified version for VERSIONWITHBUILD, print a warning if the prerelease/build data is non-numeric and replace it with .0
   Example:

• User sets 1.0.0+123
  • VERSION == 1.0.0+123
  • VERSIONWITHBUILD == 1.0.0.123
• User sets 1.0.0+build123
  • VERSION == 1.0.0+build123
  • VERSIONWITHBUILD == 1.0.0.0 but with a warning log

One thing that i'm unsure about is the prerelease data so 1.0.0-beta instead of 1.0.0+beta. This is currently ignored in the versionwithbuild logic. I guess that's fine though and good in context of my other comment because it means that updating should already work fine.

[unknovvn]

I have reverted changes, added warning log. Now it should work as you have described it