This week we had a moderate number of bugs but almost all of them were "pre-triaged" by your hard-working WiX virtual team. Even so, the meeting was chock-full of news about WiX v4, a pull-request review, and news from yours truly about bugs.
WiX v4.0 status
Today Rob reported success building WiX v4 end-to-end from source to setup with the new repository organization. Some parts aren't yet included, like Burn and the WiX extensions, but enough of WiX v4 is building to be able to bootstrap its own MSI packages.
Rob also hinted at the new pipeline model and promised to provide more details at the next meeting. To those of us who build on top of and extend WiX, this new model is really exciting and we're anxious to discuss it and start hammering on it.
Issue triage
Burn: Variable of type "version" with no value causes Burn to crash without any proper indication., from @Farrukhw, points out that Burn shows an error -- not a crash! -- when a bundle version variable is initialized to an empty string. We agreed it should be a valid value and not an error, so we took the issue in WiX v4.x for remediation.
ProgressDlg shows "Copying new files File: [1], Directory: [9], Size: [6]" on Windows 10, from @eteeuw-groeneveld, is another report of badly-formatted action strings on Windows 10. This is a change in behavior in Windows Installer and nothing that WiX can control, except by including localized strings so Windows won't try to provide them.
Toolset Installer does not install in correct location for Build Tools, from @auxym, is another instance of the MSBuild v15 change in how the formerly-reliable
MSBuildExtensionsPath32
property is now interpreted. Replacing its use with the new authoring in the Visual Studio Extension project templates is the best way of handling all of MSBuild's different personalities.
Pull request review
Rob spent some time reviewing Sean's pull request to reduce the strict interface model used between Burn and bootstrapper applications. Moving to a message-based model helps "future-proof" both the Burn engine and bootstrapper applications.
The Great WiX Bug Purge
In last week's meeting's "after show," those of us who stayed on the line discussed the desire to get rid of some/many of the old bugs in the issue tracker that are almost certainly never going to get to the top of anyone's to-do list. To that end, we're targeting bugs that are
- Open
- Unassigned
- Untouched in more than two years
Those bugs will be:
- Closed
- Assigned to the new
RespawnPoint
milestone - Labeled
not-dead-yet
(or perhapspining-for-the-fjords
?) - Commented on to describe their not-quite-dead state.
Our goal is not to kill off genuine bugs that someone is interested in fixing. Anyone interested in fixing one of these bugs is welcome to comment on the bug and we'll arrange a respawn. But bugs that nobody has worked on in years are just a distraction.
I'll announce when the bug killer tool is ready. Maybe we'll run it live during a meeting!