Today's meeting happens only a week after our last one, a jarring change from our usual fortnightly schedule. It was for the good reason that we wanted a final checkpoint before our release of WiX v5 on Friday. Did we need that checkpoint? Were awful, recall-class bugs reported in the last few days? Are we shamefully slipping our schedule? Read on to find out! (But no, no, and no.)

WiX v5 release plan

We can summarize the WiX v5 release plan as "so far, so good." So good, in fact, that our schedule remains unchanged:

  • v5.0.0-rc.1 on 8-Mar-2024 (done!)
  • v5.0.0-rc.2 on 22-Mar-2024 (done!)
  • v5.0.0 on 5-Apr-2024

Now is almost your last chance to make Rob and/or me do a late-night debugging session to fix a last-minute bug. Give it your best shot! We dare you.

Issue triage

  • Add support for non-SNI SSL certificate in WixToolset.Http, from @solidstore, is an issue tracking an in-progress pull request that didn't happen in time for WiX v5. We added it to the v.Future milestone to look at again for WiX v6.

  • Temp directory issue after wix v 4.0.5 upgrade, from @DipakTated, is a bit of fallout from our recent security releases. We haven't yet been able to reproduce the problem here at FireGiant and we're a bit reluctant to make speculative fixes in an area that's still tender from a recent security fix. So Rob volunteered to keep trying to reproduce it and provide a safe fix.

  • Consider relisting the vulnerable package versions, from @WGroenestein, requests that we list the vulnerable NuGet packages that we delisted so that a vulnerability scan would detect them. We decided the risk was greater that more people would consume relisted packages than would run the vulnerability scan to detect them. Also, it seems that the vulnerability scan has a bug/bad design that it doesn't look at explicitly-listed vulnerable packages.

  • WiX3.14 release binaries contain incorrect file versions , from @oleg-shilo, points out that assemblies in WiX v3.14 have different file versions and product versions. That's true and, as a matter of fact, has been true for many years. And, naturally, there's an obvious and very good reason for that apparent oddity.

  • References to native nupkgs use WiX v4's upper bound, from @robmen, demonstrates that having multiple ways to specify versions is both fun and exciting. In this case, dependencies to other WiX NuGet packages were specified as 5) which specifically excludes v5.0.0 -- though, thanks to a funny SemVer quirk, includes v5.0.0-rc.2, so we wouldn't notice until we actually shipped v5.0.0. Rob fixed the version specification this morning.

WiX v6 Git strategy

In a bit of thrilling behind the scenes detail, Rob shared how we're going to restructure the WiX repo a bit for WiX v6. A lesson we learned after shipping our recent security releases -- a harsh teacher, to be clear -- is that our current model made it more difficult than necessary to ship multiple releases simultaneously. While we certainly hope never to need to do that again, it makes sense to choose a model that better fits our (potential) needs.

So after WiX v5 ships, we'll reorganize the wix repo to switch to a release flow/trunk-based development model. Development happens as it has for years, now a branch named main (instead of develop) and releases happen on release branches that are short-lived and replaced by tags after release.

Day-to-day development is still "send a pull request targeting the default branch" -- the only thing that changed is that the default branch is now main instead of develop.