We, the maintainers, love pull requests from everyone, but often find we must say "no" despite how reasonable the proposal may seem.
For this reason, we ask that you open an issue to discuss proposed changes prior to submitting a pull request for the implementation. This helps us to provide direction as to implementation details, which branch to base your changes on, and so on.
- Open an issue to describe your proposed improvement or feature
- Fork https://github.com/jamesdphillips/graphqlgen clone your fork to your workstation
- Create your feature branch (
git checkout -b my-new-feature
) - If applicable, add a CHANGELOG.md entry describing your change.
- Push your feature branch (
git push origin my-new-feature
) - Create a Pull Request as appropriate based on the issue discussion
The Changelog is based on keep a changelog v1.0.
All new changes go underneath the Unreleased heading at the top of the Changelog. Beyond that, here are some additional guidelines that should make it more clear where your change goes in the Changelog.
Any new functionality goes here. This may be a new field on a data type or a new data type altogether; a new API endpoint; or possibly a whole new feature. In general, these are sentences that start with the word "added."
Examples:
- now support 2018-10-01 version of GraphQL spec.
- added support for list type.
- updated parser to support list type.
Changes to any existing component or functionality of the system that does not cause breaking changes to users or developers go here. Changed is distinguishable from Fixed in that it is an intentional change to existing functionality.
Examples:
- Refactored executor to support parallel execution of fields.
Fixed bugs go here.
Examples:
- Fixes issues with parsing list tokens with parentheses present.
Deprecated should include any soon-to-be removed functionality. An entry here that is user facing will likely yield entries in Removed or Breaking eventually.
Examples:
Parallel
configuration option is no longer supported.
Removed is for the removal of functionality that does not directly impact users, these entries most likely only impact implementors. If user facing functionality is removed, an entry should be added to the Breaking Changes section instead.
Examples:
- Removed references to
encoding/json
in favor ofjson-iter
. - Removed unused
Store
interface forBlobStore
.
Any fixes to address security exploits should be added to this section. If available, include an associated CVE entry.
Examples:
- Upgraded build to use Go 1.9.1 to address CVE-2017-15041
- Fixed issue where users could view entities without permission
Whenever you have to make a change that will cause implementors to make changes to their code.
Examples:
- Previously deprecated list types are no longer supported.