Navigating API versions and changes can be complicated, and for most scenarios, it is not necessary. We have put considerable planning at the outset of our public API to avoid breaking changes to the schema. However, we do acknowledge that sometimes a change is necessary, and it will fall into one or many of these categories:
Enhanced Functionality
User feedback, industry best practices, and emerging technologies drive these changes. This design will make your development experience even more seamless and powerful.
Performance Optimization
Our schema changes aim to optimize data retrieval and processing, ensuring your applications perform at their best, even under heavy loads.
Security and Data Privacy
In a rapidly evolving cybersecurity landscape, SportsEngine has a solid stance to protect minor data and stay ahead of potential threats. Our schema updates include enhancements to safeguard your data and protect against emerging vulnerabilities.
We will always have a transition timeframe for breaking changes. During this timeframe, the previous and new options will be available simultaneously. When use stops or when we reach the end of the timeline, the schema will delete previous options. Our changelog will record all updates.
Note: Changelog is available in the SportsEngine community forums here.
Schema Additions
New attributes, enumerations, objects, queries, and mutations will appear in the schema immediately as they are available. Once they appear, they will follow these other policies around changes or deprecation.
Modifying or Removing Attributes & Enumerations
If it is necessary to change an attribute name, which we will strongly avoid, the old and new attributes will be available for a minimum of 90 days. The transition timeframe is in the schema documentation and posted in our changelog. It is important to note that all change timeframes are the minimum. If a timeframe lands on a non-business day, the change will take effect the next business day.
Enumeration changes that list available values for an attribute (e.g., status) will follow the same process as attributes with a 90-day timeframe.
Changing Input Signatures for Queries & Mutations
Changing a query or mutation signature/input will involve leveraging default values not to break existing integrations.
When a signature change breaks existing integrations, the previous and new signatures will stay supported for a minimum of 180 days, and the change will update to our changelog.
When an entire query or mutation is deprecated, it will stay supported for a minimum of 180 days. As well as noted in the schema and posted in our changelog.