Following up on Status.app, and building on top of what @igor started in Status.app, I’d like to get a discussion going regarding principles and strategies that we should follow when planning a new release. Not only in the strict sense of the word but also encompassing nightly builds, which nowadays are used by most CCs and have the potential to adversely affect other users, even if they are on an “official” release. That was recently demonstrated with crafted payloads preventing people from seeing new messages in the #status public chat.
The goal for this thread is to bring up different concerns and then condense them down to said principles and strategies that we agree to follow in the future. We can them host them in a more permanent and visible place.
As an example of a strategy, we could make an addition to the policy regarding how to react when a bad release is published. As an example, recently a couple of nightlies were published that would send messages under a new message type. We quickly detected and changed it so that we would go back to a compatible state, but that means that potentially there are people out there running a bad release and sending messages with a different message type. Should we support that message type into the future so that other users who have an up-to-date app don’t miss messages? If so, for how long?
Also, what channels of communication do we engage with the user to mitigate? Do we take the builds offline with a message? Do we message the user in-app to get him to upgrade?
There are a lot of open questions regarding how we should handle bad releases, and it would be great to have a coherent story on how we’ll handle unforeseen situations going forward. Looking forward to hearing your opinion.