WiX Online Meeting 250 Highlights

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.

Communication

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:

• For announcements and news, you have a choice of the WiX web site news section, this well-written and engaging blog right here, and the GitHub discussions announcements category.
• For general support, Q&A, and discussions, the primary channel is GitHub discussions. FireGiant support customers continue to get individual support with guaranteed response times on both WiX v3 and v4. You can also post questions (though not discussions) to Stack Overflow.
• For discussions around developing WiX itself, use GitHub discussions in the WiX Development category.

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

Cadence

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.

Categorization

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

• v3 to v4 conversion of a Merge Module isn't as pretty as a Package, from @chrpai, came back to triage after being closed -- and was reopened after some discussion that happened live in the YouTube chat interface. See, that's the kind of interactivity that can happen live, though of course reading these bespoke highlights after the fact is almost as satisfying...um, right? Anyway, this issue became our first up for grabs issue.

• WiX v4 compression does not create files as small as v3, from @Mertsch, was closed due to lack of information. At the moment, we see minor differences due to, for example, custom action DLLs being slightly different sizes due to compiler differences.

• Minor upgrade removes all files and uninstalls services, from @mjanulaitis, demonstrated a bug in Burn when using minor upgrade MSI packages. Sean investigated and sent a pull request, which he and I talked about briefly, and then we talked some more today. We decided to take the PR almost immediately, so the fix will be available in -rc.2 tomorrow.

• Wix cannot work with DebugType embedded, from @ChristianSauer, points out that the WiX MSBuild targets uses DebugType to indicate the "type" of .wixpdb file to generate: full or none. However, the MSBuild targets for Visual C# also use DebugType, but has a different set of possible options, so a global DebugType value set in a shared MSBuild project fails for values other than full. One option would be to introduce a new property for the WiX targets; my non-copyrighted arachnid-apprehension superpower triggered at the idea of introducing a new property during the -rc cycle, so Rob agreed to add a warning when using DebugType values that WiX doesn't support.

• HarvestDirectory's generated payloads .wxs file do not produce bal:BAFactoryAssembly="yes" attribute for BA's major payload. Produced .exe fails to start BA., from @pkorsukov, is a feature request to fully automate the authoring needed for managed bootstrapper applications when using payload harvesting. Nobody in the meeting expressed an interest in implementing this feature, so we once again applied the up for grabs label.

• WIX0001 System.ArgumentOutOfRangeException: Index and length must refer to a location within the string., from @manikandankkr, is possibly an interesting issue but lacks any of the detail we need to diagnose the problem. We've requested more information while simultaneously wishing that we had the information now so if there's a bug, we might have fixed it today and published it in WiX v4 -rc.2.