4 ms·
It’s not much of an apology because the final paragraphs try to push any future responsibility onto the SDK consumers by saying they should make sure they are u
by cflewis 6y ago
It’s not much of an apology because the final paragraphs try to push any future responsibility onto the SDK consumers by saying they should make sure they are updating as fast as FB would like them to.
It’s an odd addendum to put in and appears ominous to me.
- asdfasgasdgasdg 6y agoIf they want to push that responsibility they should do it officially rather than as a suggestion. The company I work at has a concept called a "build horizon." The rule is that clients have to be updated within the horizon. Internal services do not have to consider internal clients older than the horizon, and may break them arbitrarily. In effect this means that even the least with it internal clients rarely let their internal releases languish more than about half the length of the horizon, because of the associated risks of missing the cutoff. There are many similar successful concepts that cap the maintenance window that services must tolerate, while at the same time giving developers enough forewarning to understand what is expected of them.