Emergency Chat for Windows 2.2.1 released, and a point on writing release notes

Hours after Emergency Chat 2.2 for Windows 10 was released on Monday, I found a bug it had created that I’m pretty sure it wouldn’t have been possible to suss out via unit testing. I fixed it right away, since it only took adding one line of XAML to fix, tested the app thoroughly over a few more days, then published an update today after finding no other issues.

Here are the update notes as non-technical customers will see them on the Microsoft Store app:

• Fixed the caption buttons not displaying correctly in some cases on the desktop.

And, in case you’re a developer who’s interested, here’s the commit message of the single Git commit containing the fix:

Fix caption buttons drawing the wrong backgrounds on window deactivation when a light/dark mode other than the system default is used

Now, shipping a point release shortly after a major release to a digital distribution platform that only displays update notes for the most recent release, such as the Microsoft Store, presents a unique (and, IMO, completely unnecessary) conundrum:

If the notes contain the changelog for just the point release, customers who haven’t seen the notes for the major release will never see them after the point release becomes available, unless those notes are made available elsewhere such as on the app’s website (as is the case with Emergency Chat for Windows), or in the app’s README file or About section.

There are several ways an app publisher can approach this:

1. Write the notes for just the point release anyway, screwing over customers who haven’t seen the major release notes and have no way to look them up elsewhere. Even if you don’t want me using such strong language¹, it’s still potentially leaving customers none the wiser that there was a recent major update, especially if your version numbers aren’t semantic and/or if your customers don’t understand your versioning scheme.

2. Reuse the notes for the major release. You may be able to get away with this if the point release changes or corrects something so obscure that hardly anyone would notice there was a difference, and the change doesn’t seem worth mentioning. But I’d urge you to reconsider if it really isn’t worth mentioning.

3. Write the notes for the point release and include a copy of the major release notes underneath. I think this is a decent compromise, and an especially good one if the release notes are short enough. However, keep in mind many platforms (the App Store on iOS being one example I can relate to) truncate the release notes and have the user expand them at their own leisure, and some customers may potentially miss the major release notes as a result.

4. #3 but in reverse, so the major release notes come first. This sounds interesting on paper, but if your changes are worth mentioning in the first place (even if only for bookkeeping purposes), you may not want your major release notes to cause them to disappear under the fold, especially when the major release notes are very substantial.

These are just my speculative and subjective analyses of each approach; your views, experiences and even data may suggest something different and I welcome anyone sharing their thoughts. But, based on my own analyses and the brief nature of the notes in this case, I’ve taken approach #3, at least with this particular point release. Here are the update notes in full:

Version 2.2.1.0:

• Fixed the caption buttons not displaying correctly in some cases on the desktop.

Version 2.2.0.0:

• You can now use the app in light or dark mode independently of your system settings.
• Updated the acknowledgements.
• Performance and reliability improvements.

If Emergency Chat has helped you during a time of need, or if there’s something that you think can be improved, we’d love to hear from you! Please rate and review our app (you can do this from within the app by going to Settings > About).