Today's meeting is the last in 2022: We agreed that a meeting between Christmas and New Year's Eve (or Day) would probably be sparsely attended, what with being full of Christmas goose and/or spiked eggnog. So we're pushing the next meeting to 5-January, which lines us up well for the next release candidate build of WiX v4 -- no, not -rc.1, that's tomorrow -- the one after that.

WiX v4 release plan

The WiX v4 release plan is much as we've been discussing: We're on track to ship rc.1 tomorrow, 15-December. The rc.2 release is planned for 20-January in the upcoming year of 2023. We'll likely have (a?) further -rc releases, roughly once a month until we're confident we've squished the bugs in WiX v4. Then the -rc tag will be removed, a stable WiX v4 will be pushed to NuGet.org, the release will be celebrated with cake and adult beverages, and planning and thinking about what's in the next version of WiX will begin.

Issue triage

  • ServiceInstall element's Type enumeration missing "per-user service" options, from @christopher-rtf, requests that WiX support the new-to-Windows-10 concept of services that run as a user. Old school services can also run as a particular user but have to be installed per-machine. I'm betting that Windows added this kind of per-user service primarily for Windows' own use, primarily because of the annoying limitation that such services are only started when a user logs in. Currently, there's no support for them in Windows Installer and even the Service Control Manager documentation doesn't address them, so we deferred this issue to the next release to see if per-user services are generally supported for developer use.

  • Burn should register InstallDate , from @robmen, is a suggestion that Burn should write the date a bundle was installed to the ARP registration key to prevent the ARP/Programs & Features/Apps and Features code from having to try to deduce the installation date. (Why the Windows team didn't just say "no InstallDate? leave it blank!" is a mystery for the ages.) Rob said this seems like a simple enough feature that he'll make sure it gets into WiX v4-rc.2.

  • WiX SDK should be documented, from @barnson, is a todo-list issue for some of the work I've been doing on the WiX Web site. I ported the DTF manual to the WiX site for preview.1 but the DTF class library reference manual was a bigger job. That job is now done and as the public WiX assemblies also have documentation comments, I added them to the site too.. So the remaining work in this issue is for the native parts of the WiX SDK, specifically DUtil and WcaUtil. That's an even bigger job as there isn't a standard for doc comments. The closest is probably Doxygen, which I'll be investigating to see if we can add those libraries to the site as well.

  • v3 to v4 conversion of a Merge Module isn't as pretty as a Package, from @chrpai, demonstrates that converting a WiX v3 source file for a merge module leaves behind a poorly-formatted WiX v4 source file. Getting whitespace right when manipulating an XML file is challenging. @cpuwzd did some good work in the wix convert code to make that work well, so we requested his help investigating this issue; as he was in the meeting live, he agreed then and there.

  • Include full Burn version in log, from @rseanhall, points out that a digits-only version for Burn is missing a lot of data, because the full semantic version narrows down the version to a particular commit. I volunteered to take care of this issue, because I'm already a big fan of GUIDs, so SHA hashes are next on my list.

  • API doc generator has bugs and Schema doc generator has bugs are both tracking issues for the known bugs and limitations in the tools I wrote to generate some of the reference documentation on wixtoolset.org. I'll continue to work down the list as time permits.

  • Failing to get update feed should not block bundle progress, from @robmen, suggests that a failure to find a bundle's update feed shouldn't be a fatal error. While a missing or bad update feed is very sad indeed, I agree it shouldn't be fatal, so I picked up this issue to fix for rc.1.