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…
When we first started talking about the WiX v3.x series and WiX v3.8 in particular, we were already behind schedule in getting support for Visual Studio 2013. That was the forcing function for WiX v3.8 itself: WiX v3.8 had to ship on a schedule and it wasn’t a schedule of our own making. Luckily, that’s just one reason to ship a release:
- To support a platform. For WiX, that’s primarily Visual Studio and Windows. It’s a time-boxed release with the time box outside our control and usually imprecisely defined. This was the case for WiX v3.8 though luckily we had a fairly precise time box.
- To make particular functionality generally available. Because a lot of organizations frown on “beta” software, there’s value in shipping when we have something interesting to ship. There’s no time box involved; it’s a judgment call based on the accumulated set of bug fixes and implemented features. WiX v3.7 shipped in this model, to release the support for self-updating bundles.
- To meet a self-imposed date. This is the classic Scrum time-box model: Every sprint produces a potentially shippable release and every so often, you ship one. The idea of shipping every so-many months is pretty powerful. It ensures users get updates on a predictable schedule. Even better, developers working on new features get them into users’ hands on a predictable schedule and don’t have to worry that what they’re working on won’t see the light of day for years.
So what does this have to do with WiX v3.x?
One of the things I was hoping to hear at the Build conference earlier this month is rough dates for the next “big” releases of Windows and Visual Studio. Rumors abound but it would be nice to plan WiX releases based on something a bit more firm. Assuming the rumors are semi-accurate, we have a year or so before we next have a schedule forced on us. I see three options:
- We slip the WiX v3.9 schedule into 2015, to support the 2015 Windows and Visual Studio releases.
Pros: We wouldn’t have the extra work in doing two releases.
Cons: We would go a year and a half between WiX v3.x releases.
- We ship WiX v3.9 soon to give more time to the WiX v3.10 schedule.
Pros: It gives development time to when we (should) have more details about the 2015 releases of Windows and Visual Studio.
Cons: We’d want to ship WiX v3.9 in the next couple of months which means quickly ramping down on the scope of changes we’d take into v3.9.
- We give more time to WiX v3.9 and shorten the WiX v3.10 cycle to focus only on platform support.
Pros: We could keep taking bigger changes for another month or two.
Cons: Without official dates, we’re reduced to reading tea leaves and entrails for planning. That leaves a bigger risk we could be unprepared if the rumored schedule changes or if the platform work takes more time than anticipated.
Given the pros and cons, I’m proposing option #2: We ship WiX v3.9 soon, in the June/July timeframe. That would give WiX v3.10 10 months (based on current rumors) to prepare for a new version of Windows and Visual Studio.
Feedback? Post it on the wix-devs mailing list. No matter your preference, if you have bugs or features you want to see implemented in WiX v3.x, go grab one and send a pull request. There’s no time like the present.