A new Street Fighter coming out, an upcoming Tears for Fears album, and constant background fears of nuclear war: Lots of late-80s nostalgia going on today, as we spend an hour discussing a single issue.

Issue triage

  • Burn should expose bundle's upgrade code (and id?) as variable, from @barnson, came back to triage after Sean began investigating BundlePackage should handle DetectCondition, which also led to RegistryKey BundleUpgradeCode includes GUIDs of all related bundles. All of these issues are related to Burn's concept of related bundles. (That pun was unintended, really.) Related bundles allow a bundle to declare that it somehow "related" to other bundles. You can also declare what type of relationship those other bundles have to yours. For example, you can declare that you're a patch bundle for a "base" bundle. The type of relationship determines what Burn does if it detects the related bundle. For example, if you declare that your bundle upgrades another bundle -- and if your bundle is a higher version than that other bundle -- Burn will install your bundle and, at the end of the chain, uninstall the other bundle, which typically just cleans up the old bundle's cache and registration. However, even though the Bundle element has an UpgradeCode attribute, during compilation that upgrade code turns into just another related bundle entry. That means that a bundle's upgrade code isn't special and another bundle can declare the same upgrade code and basically "hijack" another bundle. That's intentional behavior but can be surprising. After an hour of discussion, we concluded that we really ought to document the entire spectrum of related bundle relationships and their behavior, so that we can talk a bit more intelligently about what we think should happen. To that end, I took RegistryKey BundleUpgradeCode includes GUIDs of all related bundles and will practice my drawing skills for that discussion in the WiX v5 timeframe.

  • Bring back option to verify payload by Authenticode signature, from @rseanhall, comes back to the triage team with Rob reporting that he'd investigated the questions around the issue and concluding that the effort applies now to remote payloads for ExePackage and MsuPackage. The issue is at the top of Rob's queue of WiX v4 work to be done.

GitHub Actions problems

Rob reported that our GitHub Actions builds are now working again. We suspect it's from the deployment of the latest build machine VMs, which include Rob's change to get ARM64 libraries in the image, so they no longer require us to install them as part of the build. There's no definitive explanation from GitHub, so we're going to just cross our fingers and hope it keeps working.