Today we triaged some issues, discussed some low-level designs for WiX v4.0, and, for a change of pace...triaged even more issues. Specifically, today and for at least a couple more meetings, we're going to triage issues assigned to WiX v4.0 so we can determine the best way of handling them prior to the release of WiX v4.0.

Issue triage

WiX v4 design discussion

We have a few design issues that need the massive braintrust that is the WiX Online Meeting. Today, we discussed "the" Burn API. In WiX v3, the APIs that Burn used to communicate with a bootstrapper application and that the bootstrapper application used to communicate with Burn were COM(-like) interfaces. A downside to interfaces that we encountered several times during the development of WiX v3.x is that interfaces cannot be changed without breaking binary compatibility. In a couple of instances, we accepted that breakage because you generally just needed to recompile your BA.

In WiX v4, Burn now uses messages instead of interfaces. Messages allow us to make backward-compatible changes and retain binary compatibility with BAs that were built with earlier versions of WiX. A downside is that the message-based API is a bit more cumbersome than the old interfaces. Luckily, Sean has done the work to replicate similar interfaces in WiX v4, for both native and managed code.

The question that Rob and I had for Sean was whether both messages and interfaces were (or should be) the "official" API for Burn in WiX v4. That pivoted into a discussion whether the message-based API could be hidden, keeping the interface-based API as the One True API.

In the end, we decided to keep both interfaces available for maximum flexibility.

WiX v4 old issue triage

As we discussed at prior meetings, we need to triage the issues already assigned to the WiX v4.0 milestone. Today we decided to put them all into one of the following buckets:

  • closed because we no longer believe the issue should be implemented.
  • v4.x because we don't believe it's necessary for WiX v4.0 but want it eventually.
  • v.Next because we don't believe it's necessary for WiX v4.0 and want it but it involves a breaking change that can't be made in a WiX v4.x release.
  • wix.4.0-preview.1 because we believe it needs to be implemented in WiX v4.0.

The wix.4.0-preview.1 project is to identify all the known work we have for WiX v4.0. It's the feature-complete milestone; any milestones after that will be bug fixes only. (OK, yes, it's likely that we will be a bit more flexible than that, given the nature of shipping software.)