Welcome to the highlights of the 250th WiX Online Meeting! Just 750 more until Meeting 1000. We celebrated that meeting milestone by introducing some important changes to how we build and communicate about WiX. Read on for the details.

WiX v4 release plan

We continue to march along to the WiX v4 release plan: The -rc.2 build ships tomorrow, on 20-January. The -rc.3 build now has a (scheduled) date: 24-February. As always, we're relying on you to:

  • Use WiX v4 prereleases.
  • Find any bugs.
  • Report those bugs.
  • So we can fix them.
  • And then build another prerelease.
  • So you can keep using prereleases.
  • Repeat until done (aka GOTO 10).

We're looking forward to getting to "done," so we can start working on WiX v5.

Getting things done, the next generation

Now that WiX v4 is nearing its release, we-the-WiX-committers have had some time to start thinking about the proverbial What Comes Nextâ„¢. So we thought about and talked about how we might do future work in WiX differently than we did WiX v3, v3.x, and v4. Rob broke this thinking down to three topics.


In 2004, WiX v2 was released over on SourceForge. One thing that has remained constant in the almost 19 years since is that the primary communications channel for WiX has been mailing lists, specifically wix-users for user discussion and wix-devs for developer discussion. That's changing. Traffic to the mailing lists continues to decline and we've had enough problems with the archives that we decided it's time to move on from solutions that would work over a teletype. Specifically, these are the channels we'll have going forward:

The mailing lists will be shut down and archived later this year.


Not quite 10 years ago, I set out the plan for what would turn out to be the next five releases of WiX v3. It was not my intent to follow that plan for quite so long; I assumed we'd have a few releases and then switch our focus to WiX v4 so we could introduce new, larger features. Well, that also didn't go according to plan. WiX v4 took years longer than it should have. To help prevent that in the future, we're changing our mindset by planning to focus on annual major releases. Such time-boxing gives us an easier way to say no to ourselves when we want to say "just one more feature." (You've done the same thing, admit it.) Focusing on annual releases helps us avoid distracting ourselves with other, smaller releases on conflicting schedules.

A hand-wavy schedule that we'll refine as we go through this process a few times has:

  • About nine months of development, testing, and bug fixing, resulting in a feature-complete -preview.1 prerelease.
  • About a month of bug triage and bug fixing, resulting in a -rc.1 prerelease.
  • Another month of bug triage and bug fixing, resulting in a -rc.2 prerelease.
  • A final month of "bake time," resulting in a final release.

Our hope is that with limited development time, only a handful of prereleases are needed to reach release quality.


Aligning with our new schedule cadence, we decided to simplify how we categorize issues during triage. We used to decide if an issue is something that should be done and if so, whether any of the WiX maintainers or those in the meeting live wanted to volunteer to take on the issue. Then we decided when an issue should be resolved: Sometimes it's immediately, like during our recent triages of WiX v4 issues, but if it's not now, we've used our v3.x, v4.x, and v.Next milestones to suggest when issues should be done.

We're making it all easier. Starting today, if an issue goes through triage without a volunteer, it's given the up for grabs label and not assigned to a milestone. When someone wants to fix a bug, they can leave a comment stating such and we'll bring the issue back to triage to determine the milestone it should live in.

Note that adding a comment to an up for grabs issue along the lines of "any updates to this issue?" will be ignored (at best). An issue is up for grabs because nobody volunteered to fix it so until somebody does volunteer, it's not going to get worked on. (One exception is that if you're a FireGiant customer, we'll fix your bugs because we love you. And because we signed a contract saying we would.)

Issue triage