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
Preprocessor condition is always true regardless of the value of A, from @wixbot, was revived after being triaged years ago because cpuwzd researched it and submitted a pull request. However, after discussing it, we decided that coercing string-based preprocessor variables to boolean values is the wrong thing for the preprocessor to do. We decided that instead,
<?if $(var.A) ?>should be an error, as it can be more clearly replaced with<?ifdef A ?>.Cannot create multi-arch .wixlib when using an architecture specific .wixext, from @robmen, is the result of a discussion from a prior meeting, where the new
wix.exebuild process doesn't currently allow a build that was possible in WiX v3: WiX authoring could be compiled using multiple invocations of Candle.exe to build for multiple architectures and then combined into a single multi-architecture .wixlib with a single call to Lit.exe. Rob's going to look at ways that could be accomplished in WiX v4.Switches that take arguments should report bad arguments not bad switches, from @barnson, is a slight oddity I noticed when I made a typo: Error messages that show up with invalid switch arguments are usually showing as error messages indicating the switch itself is bad. Rob volunteered to take a look.
WiX v3.14 should drop XP support to match WiX v4.0, from @barnson, is my suggestion that WiX v3.14, being the transition-to-WiX-v4 release of WiX, should have similar system requirements. Here, that means that we should stop building custom actions and Burn to be compatible with Windows XP, like WiX v4. I volunteered to make the build change.
Bootrapper after installing default intance no further installation of instances are possible, from @emnuelgebel, reports something we know but haven't discussed lately: Burn doesn't support multi-instance MSI packages. It's a known missing feature that needs research and design that currently none of the WiX contributors are volunteering to do any time soon.
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:
closedbecause we no longer believe the issue should be implemented.v4.xbecause we don't believe it's necessary for WiX v4.0 but want it eventually.v.Nextbecause 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.1because 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.)