Today, Labor Day in the United States, we released WiX v3.9 Release Candidate 3. It might also be the final WiX v3.9 release. That depends on you.
Since we released WiX v3.9 RC1 back in July, the final release has always been “just a few weeks away.” That’s still true. However, as each of those weeks has passed, you have discovered and reported to the WiX issue tracker a number of bugs serious enough to prevent us from shipping.
As the bugs were regressions, mostly in Burn, in areas that received bug fixes and feature enhancements, we decided it was better to push out the v3.9 release date to give plenty of “bake time” for those changes.
Aside: We call it bake time but that’s not a really good metaphor. It’s more like pie cooling-off time, grilled meat resting time, and probably other similar things that people who actually cook or bake can tell you about.
We’re now looking at Halloween as the release date for WiX v3.9 RTM. 31-October is two months out which feels like a long time but gives us a buffer for any other lurking bugs.
Please download RC3 and try it with your packages and bundles. If you run into problems, please report them right away. If no more serious bugs are reported, RC3 will become RTM.
Update: WiX v3.9 RC3 has been released.
WiX v3.9 RC2 has been released and is ready for you to download and test. Right now, no additional changes are expected before we release WiX v3.9. But we would take a fix to a serious-enough bug — so please help root them out if they exist. Download, try it out, and report any bugs you find.
Here are the changes since the unnumbered release candidate:
jchoover: Switch WixBA over to using engine updates.
BobArnson: Install native SDK packages when VS Express SKUs (VC++ Express v10 or Windows Desktop Express v11/v12), in addition to Professional and later.
BobArnson: WIXBUG:4456 – Look at different things on opposite sides of an expression.
jchoover: Fixed some memory leaks in the engine.
BobArnson: WIXBUG:4466 – Open icons with read-sharing in DTF.
BobArnson: WIXBUG:4476 – Add x64 deputil.lib to NativeSdkMsi.
BobArnson: Use MediaTemplate in WiX setup. Include native SDK packages when the corresponding compiler is present, not just when the corresponding SDK is present. (The SDK is needed only to create the C++ custom action templates.)
BobArnson: WIXBUG:4460 – Switch license from HTML to plain text.
BobArnson: WIXBUG:4471 – Add warning about late RemoveExistingProducts scheduling with PerfCounterManifest.
RobMen: WIXBUG:4468 – fix missed suppression of suppress signature verification of MSI packages.
BobArnson: WIXBUG:4473 – Remove Wui.csproj from Wix.sln.
SeanHall: WIXBUG:4472 – Try to clean the downloaded update bundle from the cache.
SeanHall: WIXBUG:4467 – Create path2utl for path functions that require shlwapi.lib.
SeanHall: WIXBUG:4470 – Check whether the LaunchArguments are null before trying to format them.
flcdrg: WIXBUG:4437 – Adds CopyLocal COM reference assemblies to the list of assemblies to be included in managed CA.
champloo: WIXBUG:4097 – Fixes uncaught UnauthorizedAccessException in RecursiveFileAttributes.
RobMen: WIXFEAT:4188 – deprecate switches removed in WiX v4.0
Update: WiX v3.9 RC2 has been released.
Five years ago, we released WiX v3.0 on 4-July, or, if you prefer, The Fourth of July. It’s handy to use holidays for release target dates because they tend to be days away from “day jobs” to give extra time for things like filling out release forms and writing release notes. On the other hand, holidays like today’s are a bit US-centric. They also suffer from not quite understanding how software occasionally doesn’t agree to things like schedules.
So we’re not releasing WiX v3.9 today. Lots of nice features came in around the deadline I set back in May. Add some bake time and today we’re releasing its release candidate. That means, barring high-priority bugs, we’re done with WiX v3.9. So now’s the time to help hunt those bugs. Download the WiX v3.9 release candidate and put it through its paces. If you discover rude behavior, please file bugs. Our weekly online meetings will triage them.
In discussions on the wix-devs mailing list and during recent WiX online meetings, the consensus was that we should ship WiX v3.9 this summer to give WiX v3.10 as much time as possible for platform support for the next versions of Windows and Visual Studio.
The deadline for all features and fixes for known bugs is Friday, 6-June-2014. No new features will be considered after that date. Bug fixes will be considered after that date, of course, but only if the triage team — me, Rob, and anyone showing up for the online meetings — agrees they’re must-fix for WiX v3.9.
A release candidate build of WiX v3.9 will be available the week of 9-June. The release build of WiX v3.9 will be available sometime in July.
WiX v3.10 and beyond
We also decided to start ramping down on the work that goes into the WiX v3.x series. WiX v4.0 is ramping up and we need to ensure that work done in v3.x also gets into v4.0. As v3.x and v4.0 diverge, that’s getting more and more difficult. So here are two guidelines we’ll be putting into place in v3.x work:
- The breadth of new features in WiX v3.10 will be reduced in scope. In WiX v3.8 and v3.9, we allowed most every feature request that came with a well-coded pull request. But we regularly ran into backward-compatibility issues, especially in Burn changes, where most of the features came from. There was some very clever language-lawyering of what “backward compatibility” meant. In WiX v3.10, that won’t be necessary: If there’s a question of backward compatibility, it’s a sign that the feature should go into WiX v4.0 only. In WiX v3.11 or later, we’ll consider whether any new features should go in. It might be that those releases allow only bug fixes.
- Features and bug fixes are made first in the wix4 repo and then back-ported to the wix3 repo. This bit of process ensures that WiX v4.0 is a proper superset of all the new features and bug fixes that are added to WiX v3.x. It also helps highlight the scope of a change — if it’s hard to back-port, it might just be because it’s too big a change for WiX v3.x.
There are plenty of bugs and features still marked for WiX v3.x. These changes in policy don’t mean we don’t want those bugs and features, just that as we approach WiX v4.0 becoming a production-ready toolset, we need to be aware of how much we divide our attention. As long as we have contributors willing to work on WiX v3.x, we’ll keep going.
I set up a new workstation this weekend and wanted to see how well the multi-process WiX build took advantage of the many cores I paid for. The good news is that the source-code build is about twice as fast — not bad for three times the number of cores. There’s still room for improvement, but so far, nobody’s done a “deep dive” to add the discrete project references and other synchronization needed to get maximum parallelization.
The bad news is that building the WiX bundle takes two thirds of the entire build time: 44 seconds out of 65. Two primary reasons for that:
- MSBuild can build multiple .wixproj projects in parallel but within each build, only when building multiple cabinets are multiple CPUs used. When you build an all-in-one compressed bundle, a single cabinet is built as the attached container.
- The WiX build defaults to high cabinet compression. High compression squeezes the last bit of compression — at least what passes for compression for cabinets — at a high CPU cost.
The first bullet doesn’t have a quick or easy fix. For example, if we replaced the bundle container format with LZMA, we could get multi-threaded compression but we can’t do much about the fact that MSI requires cabinets.
On the second bullet, there’s a fix that’s both quick and easy. In fact, I already blogged about it, three years ago. After remembering that, my alias to build WiX now sets the WIX_COMPRESSION_LEVEL environment variable to none before invoking MSBuild. Setup build time after that change went down to 19 seconds.
Now, to see what RAID-0 does…