Versioning suggestion

[jkimbo]

Hi @Cito ! I noticed that you've started work on Graphql.js v16 (which is exciting) and I had a suggestion around the versioning of graphql-core: since each major version of graphql.js might contain breaking changes would it make sense for graphql-core to also adopt the same version numbers? So the next version of graphql-core would also be v16. That way graphql-core maintains the semver versioning scheme and it's also very clear how it matches up with graphql.js.

What do you think?

---

I also wanted to just thank you for all your hard work maintaining this library. It's the reason that the Python graphql ecosystem can still grow and it really is invaluable. 🙏

[Cito]

Hi @jkimbo. Yes, I want to slowly catch up with recent development in GraphQL.js again.

I thought about SemVer as well, but then decided to stick with the current versioning scheme, because I fear changing it might confuse people. It was hard enough to make people understand the difference between GraphQL-core 2 (legacy) and GraphQL 3. Changing this again after they got accustomed to the new version numbers might cause confusion again and break package dependencies in the Graphene/GraphQL-Python ecosystem or force the other packages to change versioning as well, which might end in chaos.

The differences/incompatibilities between the GraphQL.js major versions are actually not so huge, and I keep the semantics, just using the minor instead of the major number: 14 = 3.0, 15 = 3.1, 16 = 3.2 etc. Also, you can import version_js from graphql to get the corresponding JS version. A different versioning scheme also gives us some flexibility to create releases independently when we have features or fixes that exist only on the Python side.

Another reason why I'm reluctant: I've noticed the trouble when Angular changed their versioning scheme from 1.0, 1.1, ... to 2, 3, 4 using SemVer now. I first believed that would be no big deal, but people really did not get it, and some seem still confused to this day. Mostly, people do not understand that since Angular 2, actually not much changed, and the really big change was only between Angular 1 and 2. They now feel as if they need to learn a new framework whenever a new version comes out, which is not the case, but causes anxiety and stress to some. And whenever there are blog articles or courses for a certain Angular version, like Angular 6, then they soon become outdated due to the title - people believe they are outdated and not relevant any more, because now Angular 12 is the current version. I do not want to create similar problems for GraphQL-core.

[jkimbo]

Ok thats fair enough and I can understand your reasoning. Just FYI I think we'll be changing the dependency range in Strawberry to ~3.0.0 (instead of ^3.0.0) so that we only track patch versions automatically.

Also do you think it's worth putting a small notice in the README to let people know that the project doesn't strictly follow semver versioning?

[Cito]

Right, changing the dependency version specifier that way makes sense. I have mentioned this in the README now, too.