No sure what you mean, but I believe it’s not possible. Mutations are write operation. There’s nothing to establish such logic in it. At least for now.
You are free to change or add aliases to your predicates in Schema. Any time. Self-generation based on something arbitrary would be tricky to deal with.
Remember that Dgraph has Schema, Query language and Mutations (JSON or RDF). It would be hard work to control all this without breaking anything.
So it’s up to you to create a versioning approach.
While there’s nothing that prevents a GraphQL service from being versioned just like any other REST API, GraphQL takes a strong opinion on avoiding versioning by providing the tools for the continuous evolution of a GraphQL schema.
Why do most APIs version? When there’s limited control over the data that’s returned from an API endpoint, any change can be considered a breaking change, and breaking changes require a new version. If adding new features to an API requires a new version, then a tradeoff emerges between releasing often and having many incremental versions versus the understandability and maintainability of the API.
In contrast, GraphQL only returns the data that’s explicitly requested, so new capabilities can be added via new types and new fields on those types without creating a breaking change. This has lead to a common practice of always avoiding breaking changes and serving a versionless API.
You can get some ideas about versioning from Apollo https://www.apollographql.com/docs/guides/versioning.html