Those with a keen eye have noticed that Facebook does not include any changelog to the numerous updates they push. This has been a mystery for years and the company has never seen the need to explain, I don’t even know why we expected an explanation from a company that can’t include a changelog.
Anyway, we finally got an explanation, albeit an unofficial one from someone who claims to be a Facebook employee working on the Release Engineering Team. The explanation came when someone on MacRumors forums called out Facebook for keeping release notes a secret.
TL;DR: “Release notes are useful for small applications with a few changes each release but are useless for large, complex applications with hundreds of developers. We’re not trying to keep secrets from you. There are just simply better ways of telling you what’s interesting when those features are ready for you.”
Here’s the full explanation:
Release notes are a contentious topic. While some people would very much like us to describe every one of the thousands of changes that go into our mobile applications each and every release, the plain fact is that is just impossible.
Many changes are under the hood for performance and bug fixes. Many changes are trivial (moved button X over Y pixels). I know you’re probably not looking for that level of detail (some are though). You’re probably most concerned with “what are the new features in the app that I may want to check out?”. That is equally hard to spell out into release notes.
Why is that? For one thing, features typically don’t release broadly to everyone at once. There’s no point in putting in a release note for a feature that you can’t yet use. We do this for scaling and quality reasons, it’s a fundamental part of Facebook. If small-scale tests of something new go smoothly, we release a feature more widely in a controlled way. Releasing new things to the many hundreds of millions of people that use our mobile apps is a methodic process.
Beyond that, there are logistical hurdles too. Release notes need to be approved and translated into *dozens* of languages. But before you can even get to that step, you need to write what the actual release notes are. This takes a lot of time away from a release manager that should be more concerned with what bugs are blocking the release than with collecting bullet points for notes that a vast majority of people don’t care about anyway. And with dozens of new features (some large, but mostly small) each release and a limited number of characters to express what has changed, which features should make the cut? How should they be described in a flat text space? Do you really want a simple text description to be your first impression of a feature?
Ultimately, we can express new features far better with walkthroughs also known as NUXs. These dialogues can allow you to control whether you want to enable a new feature, explain what value the feature aims to give you, show you how to use it. None of these things can be accomplished by putting a blurb in the App Store release notes.
Also, think about this, do you look for release notes when you go to a website? How do you know what’s changed there? Are you bothered by that? Many major websites do frequent pushes of a large number of changes. Facebook pushes dozens to hundreds of changes to the main website twice a day, every weekday. Releasing a version of an application on a mobile platform should be the same non-event that it is on the web and ever slowly, inch by inch, we are making progress to that goal.
Release notes are useful for small applications with a few changes each release but are useless for large, complex applications with hundreds of developers. We’re not trying to keep secrets from you. There are just simply better ways of telling you what’s interesting when those features are ready for you.
