Since switching which version of Firefox is the "active" one is done entirely by replacing the version selector, it would be ideal to be able to read from the version selector which version the "active" version currently is from that file itself. I believe that we want to embed this information into the file as a resource so that it can be read by other processes and (for consistency) by itself.

This bug tracks both adding the metadata to the version selector binary and also adding functionality to the updater to read this metadata. I am not aware of any reason why Firefox would need this functionality, but it may be worth putting this somewhere like updatecommon just so that we can more easily exercise it in automated testing.

Is Win32 version resource sufficient? Or do we need more metadata?

Any method by which we can accurately and reliably read from the updater is sufficient. However, we do need the version contained to be unambiguous - it needs to refer to exactly one Firefox version. Which means that the regular "display version" (ex 125.0.1) won't work here, mostly because of Nightly (where there are many updates within a major version and all have the same display version). I believe that build IDs are unambiguous, so I'm planning to use that.

So as long as we can read it reliably from an arbitrary process and as long as it's reasonable to put the build ID in that resource, then yes I'd like to do exactly that.

Implementation note: If we do end up doing that resource to store this, I suspect that reading it may be as simple as using GetFileVersionInfoW, though I haven't tested this.

Note that we are also eventually going to want "is this installation using versioned installation directories" metadata as well. Adding that as part of this bug is optional.