[wix-devs] 6210 - Burn engine should handle non-QWORD versions

[Sean Hall]

>  use both dotted versions and semver for their new bundles

Yeah, I'm not talking about the bundle version. I'm talking about the
engine version as a QWORD.
https://github.com/wixtoolset/burn/blob/6d763d9c86405644cc72530ad64978efd6ba5828/src/engine/EngineForApplication.cpp#L407

>  I didn't think "@#$%^&*" would be successfully parsed.

Yes it will be successfully parsed, that's the whole point of this issue.
Burn can't fail to parse a string as a version no matter how crazy it is.

On Sat, Jul 18, 2020 at 8:56 AM Rob Mensching <rob at firegiant.com> wrote:

> > I'll probably leave FileVersionFromStringEx alone
>
> Sure.
>
>
> > I think I'll leave the internal Burn engine version as a QWORD though.
>
> Bummer. If Burn used the new string/version struct that would allow people
> to use both dotted versions and semver for their new bundles. It'd also
> guarantee one user of the code. ;)
>
>
> > a standalone application would want "@#$%^&*" to be "successfully"
> parsed into a version.
>
> I didn't think "@#$%^&*" would be successfully parsed. The version string
> would have to be something like "1", "1.2", "1.2.3", "1.2.3.4",
> "1.2.3-preview.5" etc. I'm probably missing something.
>
>
> > . Maybe this will help - what would we call this version struct if it
> was verutil.h? Would it still be BUNDLE_VERSION?
>
> No, not BUNDLE_VERSION. What about "VERSION_PARSED"? Or "VER_VERSION"? Or
> "VERUTIL_VERSION"? Or "VER_PARSED_VERSION"?
>
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Thursday, July 16, 2020 1:55 AM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: Re: [wix-devs] 6210 - Burn engine should handle non-QWORD versions
>
> Ok, strings it is. Though I would like to point out that the struct has a
> copy of the original string (well, with the leading 'v' removed if it was
> there).
>
> Jacob, I will change the data type for all of the version variables (C++
> not Burn) in Burn to LPWSTR. That should include atomutil and apuputil.
> I'll probably leave FileVersionFromStringEx alone, unless someone wants
> that to be changed too. I think I'll leave the internal Burn engine version
> as a QWORD though.
>
> I don't know where we're storing versions as QWORDs in 3.x? I'm pretty
> sure all of the registry keys we write are strings. I'll probably add
> methods in dutil to get a BUNDLE_VERSION from a QWORD version.
>
> I can expose a CompareVersions method from the engine that takes 2 strings.
>
> I can understand why Burn-adjacent applications would want to be able to
> parse versions exactly like the Burn engine does, but I don't understand
> why a standalone application would want "@#$%^&*" to be "successfully"
> parsed into a version. Maybe this will help - what would we call this
> version struct if it was verutil.h? Would it still be BUNDLE_VERSION?
>