This week's meeting was another hours-long barn burner in which Sean opened all the bugs, Rob got assigned to most of them, and I got off with only a bit of word-related homework.
Issue triage
Burn can wrongly detect MSI package as Obsolete, from @rseanhall, is a result of Sean's investigation into ways that building a bundle gets it wrong when harvesting data from MSI packages' Upgrade tables. This is an obscure edge case that we decided wasn't a practical problem that required your dedicated WiX volunteer contributors to spend a bunch of effort to work around.
Burn error logging can get into infinite loop, from @rseanhall, unearths a potential infinite loop if reporting an error reports an error. I, for one, prefer my loops to be finite. Sean volunteered to make the fix.
v4 Tag conversion is incomplete and v4 Tag was not updated to new swid functionality, from @rseanhall, highlight remaining work on Rob's plate, which Rob gracefully accepted.
Patch can't be created when MSI got file from wixext, from @rseanhall, discovered a hole in patching -- [Ed. note: We see what you did there.] -- that Rob agreed to fix for WiX v4.0 Preview Zero.
Provides elements under chain packages get lost, from @rseanhall, discovered a bug in Rob's work to make package-dependency authoring into the core toolset. Rob volunteered to fix in WiX v4.0 Preview Zero.
Burn integration tests expect -burn.ignoredependencies=ALL to work for packages and bundles, from @rseanhall, concerns how the Burn integration tests -- in the imaginatively-named
integrationrepo -- clean up after themselves to prevent later tests from being affected from "leftover" bits. Sean, having discovered the issue, volunteered to also fix it.
WiX v4 design discussion
A long while back, I opened a feature request complaining that Burn doesn't cache a package if it's already installed. That makes perfect sense, of course: Why waste network bandwidth or disk space for a package that isn't going to be installed? However, one of the reasons Burn caches packages is to solve a common problem in the BB (Before Burn) era: to ensure packages are available after installation for repair and (for .exe packages) uninstall.
You can author a package with Cache="always" to tell Burn to always cache it but that ignores the package's InstallCondition -- the package will be cached even if it would never be installed (or ever could be).
So the feature request is to find a nice middle ground: Cache a package even if it's already installed.
For over an hour and a half, Sean, Rob, and I discussed the issue, potential solutions, and their implications. Someone (humility requires me to not mention his name) suggested that Burn should default to caching packages even if they're already installed, but only during an installation operation. That last part ensures that Burn has access to the package to cache it.
Toward the end of this bladder-stressing discussion, I volunteered to come up with better names to describe the ways that Burn can manage its package cache. For example, Cache="no" routinely confuses most people who come across it. It doesn't mean that a package won't be cached -- Burn caches packages in a secure location, so caching serves to prevent tampering -- but that it won't remain in the cache. However, as the saying goes, there are two hard problems in computer science: caching, naming, and off-by-one errors.
The new names I came up with are:
keep(today:yes)remove(today:no)force(today:always)
Look forward to that change in WiX v4.0 Preview Zero.