Support display version in metadata

[andydotxyz]

Checklist

• [X] I have searched the issue tracker for open issues that relate to the same feature, before opening a new one.
• [X] This issue only relates to a single feature. I will open new issues for any other features.

Is your feature request related to a problem?

It was noted in a few discussions on Discord that Fyne app metadata does not support full semantic versioning. This is due to limitations imposed by many OS (such as Windows int16.int16.int16.int16 version format or iOS int32[.int32[.int32]].

Is it possible to construct a solution with the existing API?

As we must support lowest common denominator to be compliant with all systems this is not currently possible.

Describe the solution you'd like to see.

Many systems support additional presentation format for versions (iOS/macOS "DisplayVersion" or Windows "ProductVersion"). If we could add this to FyneApp.toml then it could be used there and also in About screens inside applications etc.

[andydotxyz]

For context here is a screenshot of Windows file versions - you can see that the default is to use x.y.z.p which is replicated for display (Internet Explorer, any Fyne apps). Binaries (like Go) often have no version information but it is possible to provide a more complex string content (as GoLand in the image).

[lostdusty]

Android also doesn't bother with version

+1 for the feature. Maybe we could have a field like code_version replacing the current version, while version would be the displayVersion/productVersion/etc

[andydotxyz]

However we do implement it won't be with a breaking change. The Version field will continue to be the OS level version code used to determine uniqueness and upgrade ordering. If Android or other platforms provide full flexibility in a version string we can use the display version, if present, as an override.

[verdverm]

The reason I asked about semver, with prerelease suffix, is that we already release several things using a consistent version across the suite. We'd like to add a Fyne based project while also keeping the version consistent. In particular the download version and self-reported (./app version). We already have some code that checks and compares versions.

Overall, our goal is self-consistency. We also are not looking to create a mobile or app store. Our users typically download a binary directly.

[andydotxyz]

What you are describing can be achieved with only file naming and displaying versions in your own code. The built-in version handling we have is at the OS metadata level so that it can manage updates etc. This issue recommends extending so that we can have textual rich versions which essentially would take care of what you describe, but is not required to distribute as you suggest with download file names or version string from the app itself.