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

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.