Since the launch of Operation Developer Love, we have focused on fixing the top developer issues: documentation, bugs and stability. We have achieved some success in all of these areas including, rewriting most of the documentation, hiring a developer support team and putting a process in place to triage bugs within 24 hours. While we have seen significant improvements in each of these areas, we still have a great deal of work to do, particularly around platform stability. In short, we need to kill bugs before they exist. Today, we are announcing several resources to improve Platform stability, including formalizing our commitment to a 90 day breaking change policy and a revamped beta tier with processes to improve Platform testability.
Commitment to transparency and breaking change policy
Unexpected and breaking Platform changes are a top issue of developer concern. We pride ourselves in moving fast, but breaking apps has often been an unwanted and unfortunate consequence. Today, we are formalizing our 90 day breaking change policy. Going forward, all changes that could cause an error in your app (e.g. a breaking change) will be announced 90 days before the actual change goes into effect. We hope this provides the necessary time for adjustments as we evolve our Platform.
Because of the importance of user security and privacy, we are excluding from the new policy any change required to fix these types of issues. While we will do anything in our power to avoid even these breaking changes, user protection is the highest priority for our shared users.
You can help us keep our commitment by opening bugs if you notice a breaking change that was not announced 90 days prior. Mark the bugs in the “Breaking Change” category, and these issues will be prioritized.
Beta tier is one of the most underutilized and beneficial resources available to improve stability. Beta tier is staged with our weekly pushes (which usually take place on Tuesday evenings) on the Sunday evening prior. This provides us with 48 hours of testing before the release is pushed to production. We recently upgraded the beta tier push process to include hotfixes queued up for our daily releases as well as staging our weekly push. Beta tier is now always ahead of production tier.
We run ongoing regression suites to cover major Platform features on the beta tier, as so do some of our largest partners. Savvy developers rely on the beta tier to catch bugs before they impact production experiences. With the help of the improved Beta tier and our ability to quickly fix bugs before our weekly release, these developers have reported bugs that would have otherwise cost revenue and undermined user trust. It is important to incorporate the beta tier as part of all test plans to ensure a stable experience for users as we continue to release improvements and new features.
To further help automate tests, we have added a push status feed. Please subscribe here for a real-time feed of Push updates. If possible, hook up your automated test cases to run upon the push notification.
We have also started returning an
X-FB-Rev HTTP header on calls to the Graph API. This header indicates the internal revision number of the code running on the machine processing your API call. This can be useful data for you to isolate issues you are seeing, especially when we are pushing new code and multiple versions of our code are running concurrently. We encourage you to include the X-FB-Rev HTTP header in bug reports, if possible.
GET https://graph.facebook.com/cocacola returns HTTP headers and includes the X-FB-Rev header: <br/>
We encourage you to take advantage of the resources announced today:
Providing a stable platform is no small task, and we hope these new resources will provide the necessary foundation.
Please use the comments below to share your feedback.