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!
After a brief hiatus for releasing WiX v3.9 R2, weekly builds for WiX v3.10 have resumed. WiX v22.214.171.1243 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 v126.96.36.1990 and a theoretical WiX v3.10 SP1 might be v188.8.131.523.
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, v184.108.40.2063 will not be seen as an upgrade. The WiX BA blocks downgrades by hiding the big Install button:
The workaround is to uninstall any other build of WiX v3.10. Then v220.127.116.113 will install normally.
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.
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.
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.