Skip to Content

Serial monogamy with your development tools

Posted on

When WiX v3.0 was in early, active development, the guidance we gave folks who wanted to start using its features was: “Sure, start using WiX v3.0! But pick up new builds at least once a month or so.” There were three Reasons for Taking Frequent WiX Drops (RTFWD, for short):

  1. The v3.0 schema was changing routinely. Going months between picking up new builds would expose bigger, possibly backward-incompatible changes. New builds once a month limited a team’s exposure to whatever we could do in four weeks.
  2. When you need a bug fix, you want as small a fix as possible. Bug fixes came frequently throughout the toolset so the longer between builds, the more churn a team would pick up. That complicates validating the packages produced by a new WiX build.
  3. Output changes could complicate (or break) patching. Changes in the things WiX writes to MSI tables affect your ability to create patches. The rules governing patches are a superset of the dread component rules, adding rules about changes that make patches not uninstallable.

In effect, you increase stability by taking smaller changes at any one time.

For WiX v3.5, reason #1 doesn’t apply: We aren’t making any backward-incompatible schema changes though we’re making additive changes to simplify authoring. Reasons #2 and #3 still apply—and keep applying.

Long-term relationships

Eventually there comes a time in every project’s life to settle down in a committed relationship. For WiX users, that time is when you’re nearing a release that you intend to service. It might be a public beta, it might be RTM, it might be a weekly release of your Web app. If you intend to service it, especially with patches, you want the stability of a known build of WiX—Reason #3 applies in earnest when you start servicing.

New product releases can pick up new versions of WiX, but on the source-control branch you’re using to service old releases, stick with one version of WiX. We encourage teams to ship products using the released, RTM builds of WiX. So far, we haven’t released a service pack for WiX, but it’s safe to assume we wouldn’t include any changes in one that broke patching.

Youthful indiscretions

I was reminded of reason #3 today: Bug 2965405 demonstrated a hole in the logic that generates default component ids. The fix is simple: give a better default id used in constructing the stable short filename. Unfortunately, it changes every short filename that’s generated when you omit the Component/@Id attribute and the filename doesn’t fit within the 8.3 short filename syntax. Fixing the bug would complicate patching from prior builds of WiX v3.5.

As WiX v3.5 hasn’t even gone to beta yet, I believe we should fix the bug even with the patching problem it introduces. Other folks on the WiX Virtual Team will get to weigh in, as can you by commenting below.