As applications evolve and user needs change, the GraphQL API schemas must adapt, often necessitating non-breaking or breaking changes. While non-breaking changes, like adding a new field, can be implemented without issues, breaking changes require careful management to avoid bugs. Such changes involve removing or altering types, fields, or directives in ways that may disrupt the application. Two strategies to manage these changes are versioning and evolution, with REST APIs typically using versioning and GraphQL promoting evolution. The evolution strategy encourages continuous, incremental schema updates, making it suitable for rapid iteration. This process involves re-implementing fields under new names, deprecating old fields, and eventually removing them once they are no longer in use. This approach can lead to schema verbosity and accumulation of deprecated fields, but it allows for field versioning, enabling each field to be versioned independently. The article outlines possible solutions to these challenges, including using semantic versioning constraints and providing contextual feedback through GraphQL's extensions entry. While both versioning and evolution have their pros and cons, combining these strategies can offer a balanced approach to managing GraphQL APIs.