Another two-hour meeting today but some vital discussion about WiX v4 happening. Sadly, no more robots landing on other planets this week.
Issue triage
Enhance ability to enable debug level logging in Burn, from @rseanhall, came back for re-triage. I implemented the
/xlogswitch to get verbose/debug logging but we'd talked about the possibility of supporting per-user policy, like we do already for per-machine policy. However, supporting per-user policy has implications that need study before we can go stampeding toward per-user policy. Accordingly, and because it's additive behavior, we took this issue into WiX v4.x.Section 508 502.3.1: (Idle/link 'http://aka.ms/exporting') An onscreen element must not have a null BoundingRectangle property. and Section 508 502.3.1: (button 'Page up') The BoundingRectangle property must represent an area of at least 25 pixels., from @tgugler, continue the unfortunate tradition of reporting accessibility bugs without the context non-accessibility people like us need. The silver lining is that these particular issues should already be fixed by WixStdBA in WiX v4 using the latest rich-edit control.
WIX calculating required space wrongly to install the setup, from @kalyani1217, wants Burn to calculate the space consumed by a bundle at the level of the features that are installed. It doesn't do that today, so we took this feature request into WiX v4.x.
light.exe(0,0): error LGHT0001: The wait completed due to an abandoned mutex., from @oron89, reports a developer's favorite kind of bug: The intermittent exception. Rob's planning on working on ICE support soon and as we use a mutex in the ICE-runner code, he took this issue to investigate.
Implement Decompiler extensions and Implement cabinet spanning, both from (and for) @robmen, are tracking issues, to remind us all of work we want to complete before WiX v4.0 Preview Zero.
Sharing payloads between packages is broken, In BootstrapperApplicationData.xml, Package/@Compressed is wrong, and XxxPackage Description and DisplayName is supposed to override the information from the payload, from @rseanhall, are all issues related to the symbol and compiler side of Burn that Sean used a form of mind magic so that Rob volunteered to fix them as part of his WiX v4.0 Preview Zero work.
Minimize public surface area of WixToolset.Core and backends, from @robmen, is another code-hygiene work item that Rob wants to get into WiX v4.0 Preview Zero. In the end, WiX functionality should be exposed via interfaces instead of public classes.
Do Symbols need SectionIds?, from @robmen, asks the question whether WiX v4 symbols should record the id of the section they come from, like rows do in WiX v3. As we suspect that those section ids are used in the patch-building process, Rob volunteered to implement this issue in WiX v4.0 Preview Zero.
Bug with resolution of WixVariables defined in the wixlib, from @drolevar, reports that in WiX v4, bind-time variables are resolved when files are embedded in .wixlib files. That prevents updated bind-time variable values from specifying a different file. Rob took this issue in WiX v4.0 Preview Zero.
WiX v4 design discussion
We managed to discuss several WiX v4 design issues during today's meeting, but as has become tradition, we spent an hour on one issue: Whether and how we should reorganize the WiX Git repositories on GitHub. Early in WiX v4 development, Rob took a scalpel to the old wix4 repo -- the big ball-o'-mud monorepo that contained all the source code for all of WiX, from the native-code libraries to Burn to everyone's favorite command line tools Candle and Light to the does-anybody-still-use-it COM+ extension. Instead, WiX v4 development has continued using so-called microrepos, based on code layering and separating out the many WiX extensions. Some of the goals of the separation were to enforce those new layers of the WiX code and to let developers work in those layers without having to work in the entire WiX codebase.
That separation, however, comes at a price, at least for those of working on WiX itself: Changes often need to be made in multiple repos in a certain order to be complete. Sometimes, we get the order wrong. (OK, mostly that's just me, but still, theoretically it could affect others too.) It complicates development and testing of those cross-repo changes because often a change starts at the lowest level of Data and has to flow through Core and Tools before the diligent developer can test it end-to-end. In a monorepo, that was something that could be built and tested locally in a single atomic commit.
We agreed in principle that we could recombine the WiX v4 microrepos into one monorepo, with each former microrepo as a top-level directory. What remains as an exercise for the reader is how we can still accomplish the goals of enforced code layering with the ability to "build the world" and get a single change throughout multiple projects atomically.
This is a release engineering action/adventure movie. Stay tuned.