In the US, Memorial Day is considered the unofficial start of summer and the temperatures, at least for me here in the Midwest, are reinforcing that. It's hot enough that I'm staying in the cool indoors coding even cooler WiX features and occasionally summarizing our WiX Online Meetings.

WiX v4.0.1

Two weeks ago, Past-Bob wrote about the status of WiX v4.0.1 development. Today, Rob reported on the current status and it is, unsurprisingly, unchanged. So Present-Bob can recycle Past-Bob's words and just update the dates:

Our current plan to ship WiX v4.0.1 on 5-June-2023 remains our current plan. The rate of incoming bugs has slowed and the rate of bugs important enough for WiX v4.0.1 has plummeted. So we'll fix a couple of remaining bugs and cherry-pick the fixes in a bit under three weeksa week.

Issue triage

  • Investigate ways of specifying payload sources, from @barnson, is a tracking issue I created to consolidate issues we discussed at our last meeting. I took the issue for the slight overlap it has with an idea that's been percolating in the back of my head for years -- that explains the bubbling noise you might hear during meetings -- on creating a concept of "releases" that control things like containers, compression level, and layout separately from the rest of setup authoring. But I won't be working on it for WiX v5, so it went into the v.Future milestone. (We might not use that milestone long-term. That area of our current triage process is a bit fuzzy still.)

  • Support specifying a custom burn stub, from @nirbar, requests the ability to use a nonstandard Burn engine as an attribute of a bundle. This is an extreme edge case and not something we want to encourage at the language level. Luckily, WiX extensions can add custom command-line processing and their own custom language additions.

  • wixlib ProjectReferences don't set preprocessor variables any more, from @jmairboeck, reports an unexpected and undesirable change in behavior -- sometimes referred to as a "bug" -- in references to library .wixproj projects. They used to create the same preprocessor variables as package projects, but no longer do. We agreed this is indeed a bug and one that's serious enough to need fixing in WiX v4.0.1, which Rob volunteered to do.

  • No longer able to suppress ICE24 errors in Wix 4, from @paulvickery, suggests that, with sufficiently subversive methods, WiX v3 let you specify a package version that didn't adhere to MSI's rules. WiX v3 did that version validation only in the compiler whereas WiX v4 does it in the compiler and later in the build process when generating the .msi file. WiX v4 emits an error message for an invalid version number and error messages can't be ignored. Rob did some research into how MSI handles version numbers that are "out of spec" and found that, in this particular case -- using years as the major version -- would start failing in about 20 years. Now, one might comfortably conclude that no software shipped today will still be running in 20 years, but then people said that in the 80s and, well... We agreed this is something that WiX should support, albeit with stern warnings, which I will do in WiX v4.0.1.