WiX v3.10 Release Candidate 2 build available

After shipping “the” WiX v3.10 release candidate back in June, we finished off a couple of features that required us to wait for Visual Studio 2015 RTM to be released. We also took a couple of trivial, small, and minor changes. So it’s time for another release candidate, to make sure WiX v3.10 is ready to ship.

Download it here.

If you find a bug, please report it as soon as possible.

Update: Here’s what Rob has to say about RC2.

Here’s what happened since RC1:

WiX v3.10 Release Candidate build available

The WiX v3.10 Release Candidate build is now available! The focus of the WiX v3.10 release is supporting Visual Studio 2015 and Windows 10. As anticipated — almost like it was intentional — we’ve also fixed a number of bugs and implemented a small number of small features, but nothing big or risky.

We’re now ramping up the bug bar on WiX v3.10. That means bugs have to be really serious to get approved for v3.10. Don’t let that stop you from reporting bugs–we have plenty of numbers left in the v3.x series.

The plan for the RTM release of WiX v3.10 is to wait. Windows 10 ships 29-July and presumably Visual Studio 2015 ships shortly thereafter. As soon as Visual Studio 2015 RTM ships, we’ll put out a call for eyes to take a look and help verify that WiX continues to work with the RTM bits as expected. We’ll allow a short time to get feedback, then declare RTM.

Please download the RC release and help us get v3.10 across the finish line!

WiX v3.10 version twist

After a brief hiatus for releasing WiX v3.9 R2, weekly builds for WiX v3.10 have resumed. WiX v3.10.0.1403 is now available — and you might have noticed an oddity in the version number.

When we started discussing the need to ship a maintenance release for WiX v3.9, we realized that we had no way to easily differentiate a maintenance release from the original “final” release — or any other pre-release build, for that matter.

Traditionally, WiX version numbers have been based on using three fields: major.minor.build. You likely know why: Because Windows Installer uses three version fields and ignores the fourth. Unfortunately, when you want to keep using major.minor versioning, that leaves only one field to identify a particular build.

So we decided to switch things around a bit. We’re now versioning the WiX bundle as major.minor.release.build. The release value is currently zero and will stay that way until/unless we ship a maintenance release. For example, WiX v3.10 RTM might be v3.10.0.2010 and a theoretical WiX v3.10 SP1 might be v3.10.1.2323.

The MSI packages in the WiX bundle continue to be versioned as major.minor.build.0, so that major upgrades keep working. The same is true of WiX executables. That means that, for example, Candle.exe from the aforementioned theoretical WiX v3.10 SP1 would have a version of v3.10.2323.0.

I’d rather all the versions — bundle, MSIs, and executables — have the same version number but tagging the bundle with release information is important enough to make this change.


Unfortunately, the new versioning scheme means that new builds of WiX v3.10 are always seen as “less than” any of the already-released WiX v3.10 builds with the old numbering. That means that if you have v3.10.1124.0 installed, for example, v3.10.0.1403 will not be seen as an upgrade. The WiX BA blocks downgrades by hiding the big Install button:

WixNoDowngradeThe workaround is to uninstall any other build of WiX v3.10. Then v3.10.0.1403 will install normally.

WiX v3.10 begins and is already mostly done

The first interim build of WiX v3.10 has been released: WiX v3.10.1124.0 from wixtoolset.org. It includes support for integrating Votive into Visual Studio 2015 Preview and native and managed libraries for VS2015.

And that’s most of what we intend to accomplish with WiX v3.10. We will — of course! — fix bugs and add some small features in WiX v3.10 but the focus is on supporting Visual Studio 2015 and, if necessary, Windows 10. Rather than filling the available schedule with work, the goal is to finish the planned work quickly and be ready to ship WiX v3.10 as soon as possible after Visual Studio 2015 ships.

To do that, WiX v3.10 won’t include any large new features, to reduce the risk of long bug tails. We’ll release milestone builds around new milestone builds of VS2015 to make sure changes in VS2015 are reflected in WiX v3.10. Bug fixes and small features are welcome and a few are already queued up in pull requests on GitHub. More are welcome! Let’s talk on wix-devs.

Coming soon: WiX v3.9 release candidate

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:

  1. 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.
  2. 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.