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

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.