Release notes needed (dependencies breaking snapshots)

[tony]

Related: #15

Graphene's 2.1.7 release on July 15th bumped graphql-relay 0.4.5 to 2.0.

https://pypi.org/project/graphene/#history

This is a patch-release that breaks SnapshotTest (mentioned in graphene's documentation: https://docs.graphene-python.org/en/latest/testing/)

It's not clear what the changes / ramifications / intentions of 0.4.x -> 2.x of relay are. What's necessary in graphene 2.1.7 that graphql-python/graphene#1032 fixed.

[Cito]

We're trying to consolidate version numbers throughout the whole Graphene ecosystem while progressing towards graphql-core 3, after Graphene development has been in hiatus for a long time.

• graphql-relay < 2: used by Graphene < 2, compatible with graphql-core < 2
• graphql-relay 2.x: used by Graphene 2.x, compatible with graphql-core 2.x
• graphql-relay 3.x: used by Graphene 3.x, compatible with graphql-core 3.x

That's why this change was necessary.

Is there a concrete action item for graphql-relay-py that should be handled in this issue? Please help us by submitting very specific issues and PRs. These projects are currently maintained by various volunteers in their spare time. Any help is welcome.

[tony]

@Cito I don't want to hold up the flow. No one else except me has mentioned anything. To explain a bit more:

(If there already a release notes / CHANGES for graphql-relay-python and I'm just not seeing it, please let me know!)

Is there a concrete action item for graphql-relay-py that should be handled in this issue?

1. I think there should be a CHANGES file of what happened between versions. Whether or not it'd break compatibility, API changes, behavior changes. Also, the why's, such as compatibility between graphql are worth mentioning here.
2. Add the changes to the release notes at https://github.com/graphql-python/graphql-relay-py/releases
3. It'd be worth adding the graphql-relay compatibility to the README

Please help us by submitting very specific issues and PRs.

Hm. I think changelogs are best described by the authors that cut the release. Normally it's best to do it when it happens so it's fresh on the mind.

I'd like to, but going back into change logs to get the gist of what is happening is hard to backtrack, let alone be correct in the process. I lack familiarity with the history of the project (and its upstream/downstream dependencies, and the compatibility between them). That's different than fixing something master since it involves digging into motivations of past changes. Does that make sense?

These projects are currently maintained by various volunteers in their spare time. Any help is welcome.

Yes, I may be proposing PR's to projects in this org, I'm trying to catch up since there's a lot of action. And thanks for your contributions @Cito as well as all other contributors @syrusakbary @jkimbo @mvanlonden @jhgg @pmlandwehr!

[Cito]

You're right, creating a changelog is best done by the maintainers. This little library is normally not used directly, only by upstream projects, but yes, that's no excuse.

Will keep this open to remind myself to

• Update and improve the README
• Create GitHub releases with change notes