fix(bundler): change build metadata verification into a warning

[unknovvn]

Closes #8038

[github-actions]

Package Changes Through d50e8d5

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.