Add 'GraphQl backward compatibility policy' section to backward compatibility guide #4493
Conversation
magento-engcom-team
added
Partner: ISM eCompany
partners-contribution
|
An admin must run tests on this PR before it can be merged. |
guides/v2.1/contributor-guide/backward-compatible-development/index.md
Outdated
Show resolved
Hide resolved
…tibility guide. Move changes before the variables.
…rd compatibility guide. Move changes before the variables." This reverts commit 5b4b659
…rd compatibility guide." This reverts commit 4c81302
…tibility guide. Move changes to v2.3
…olicy' into graphql-backward-compatibility-policy # Conflicts: # guides/v2.1/contributor-guide/backward-compatible-development/index.md
…compatibility-policy
…tibility guide. Update changes from master
|
@ronak2ram - I've updated article for v2.3 with latest changes. |
|
@vpodorozh thanks for the update. looks good. |
|
Any changes to policies must get an approval by architects before merge. |
There was a problem hiding this comment.
I can't make inline comments on GitHub. Make sure you run the git rm <filename> when you break a symlink.
Add a blank line after the new heading, and change the wording to be similar to the following:
In GraphQL, the schema is the only code that can be counted as a contract.
Only the schema should be taken into account for backward compatibility.
The GraphQL codebase should NOT follow the restrictions described in this topic. For example, skip all the backward compatibility restrictions for the GraphQL PHP codebase.
…tibility guide. Change request
|
@keharper - done. |
|
@buskamuza @paliarush Please review the "GraphQl backward compatibility policy" section at the bottom of the document. |
There was a problem hiding this comment.
Should this be stated explicitly? As long as GraphQL classes/interfaces are not marked with @api, they go under the general rule of being private code.
Though it should be stated somewhere that GraphQL schema is part of public API. @paliarush should know better where this is (should be) described
|
|
||
| * In GraphQL, the schema is the only code that can be counted as a contract. | ||
| * Only the schema should be taken into account for backward compatibility. | ||
| * The GraphQL codebase should NOT follow the restrictions described in this topic. For example, skip all the `backward compatibility` restrictions for the GraphQL PHP codebase. |
There was a problem hiding this comment.
The only exception we make for GraphQL is we allow MINOR code changes in PATCH Magento releases. Any MAJOR changes are not permitted in PATCH releases. This includes MAJOR changes in schema as well as in the codebase. In the codebase we do not have GraphQL-related classes marked with @api intentionally because the project is still in the development phase and we do not want limit refactoring capabilities.
GraphQL schema is considered @api.
|
running tests |
1 similar comment
|
running tests |
|
running tests |
|
Hi @vpodorozh, thank you for your contribution! |
Purpose of this pull request
Add 'GraphQl backward compatibility policy' section to backward compatibility guide.
Wiki article with info: https://github.com/magento/graphql-ce/wiki/Approach-to-Implementation#backward-compatibility-policy
Affected DevDocs pages
whatsnew
Added the "GraphQl backward compatibility policy" section to Backward compatible development