WiX v3.9 release candidate

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.

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.

To WiX v3.9 and beyond

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:

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

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