Graphql-ruby: How about bumping to 2.0.0?

[david50407]

In Ruby gems' world, Semantic Versioning 2.0.0 is commonly used to declaring how much changes between versions.

Since we have many public API changes from 1.7.x to 1.8 (like class-based definition), IMO, how about bumping version to 2.0.0 instead of just 1.8?

[bessey]

Actually in SemVer major version bumps (1.X > 2.X) are intended to indicate _breaking_ changes. Since the new class based API is additive, it might not merit a major version bump.

That said, I believe I had to add the global monkey patch to restore !types syntax to my codebase, even to old style types, so if that is intentional and not a bug, perhaps a major bump is merited.

[thefliik]

In the development guide, it is explained this this project explicitly does not follow semantic versioning:

GraphQL-Ruby does not attempt to deliver “semantic versioning” for the reasons described in jashkenas’ s post, “Why Semantic Versioning Isn’t”. Instead, the following scheme is used as a guideline:

• Version numbers consist of three parts, MAJOR.MINOR.PATCH
• PATCH version indicates bug fixes or small features for specific use cases. Ideally, you can upgrade patch versions with only a quick skim of the changelog.
• MINOR version indicates significant additions, internal refactors, or small breaking changes. When upgrading a minor version, check the changelog for any new features or breaking changes which apply to your system. The changelog will always include an upgrade path for any breaking changes. Minor versions may also include deprecation warnings to warn about upcoming breaking changes.
• MAJOR version indicates significant breaking changes. Do not expect code to run without some modification, especially if the code yielded deprecation warnings.

This policy is inspired by the Ruby 2.1.0+ version policy.

[thefliik]

Adding a link to the versioning scheme to the top of the changelog would probably be helpful.

[david50407]

@bessey @thefliik thanks, I'm going to close this issue now

[mortik]

This is to bad... semantic versioning is there for a reason and i'm a little bit annoyed every time i see a patch release with breaking changes like 1.9.4 just now...

[david50407]

@mortik I think this is not the reason to "not using semver is bad", they give a good rule on versioning policy, but they still put the breaking changes inside the patch.

According to the answer of @thefliik, I thought there won't be any breaking changes between the patch versions, and the small breaking changes can be between the minor versions, am I wrong?

[mortik]

I dont really now if i understand you correctly - but currently i have no indication how easy it is to integrate a new release. I need to assume that every single version can introduce a breaking change which currently they do quite often... Currently you could also create a new major version with every single release the only thing changing for everyone using graphql-ruby would be the version number nothing else...

It seems like version numbers a created based on some sort of marketing reason and not based on the severity of the changes

[thefliik]

Well

1. Personally, in general, I agree with @mortik, I would prefer it if projects used semver. This being said, 90% of the work is done by @rmosolgo. If he wants to use something else, I'm totally fine with that.
2. > currently i have no indication how easy it is to integrate a new release.
   
   
   
   • Did you not read this thread? This repo doesn't follow semver, but it does have a clear version policy and also explains the reasoning behind the version policy.
   
   

[swalkinshaw]

but currently i have no indication how easy it is to integrate a new release

Yes you do since there's a "Breaking changes" section in the changelog for every version.

I need to assume that every single version can introduce a breaking change which currently they do quite often

In my opinion, this is probably a good thing. Doing some due diligence before blindly updating a gem is healthy. Simply trusting a package update since it's a minor/patch update is a bad habit in general and we see examples of this all the time.

Even if this (or any) package claimed to follow semver, there's still no guarantee they wouldn't accidentally introduce breaking changes. Detecting them is largely a manual process (especially in Ruby) and deciding what type of version bump to do is subjective.

[mortik]

Its a good thing to introduce breaking changes in a patch level release? :) seriously? Can you give me one good reason why its not possible to create a major release when you introduce breaking changes?

[swalkinshaw]

I didn't exactly say that 😄I said it's a good practice to assume that any release could contain a breaking change regardless of what kind of versioning the package uses.

[mortik]

No its not :)

[etherbob]

I'd like to respectfully ask @rmosolgo: Please reconsider your stance on SemVer. Even "minor" breaking changes can have nock on effects that introduce real costs to a downstream project.

I had my GraphQL dep set to 'graphql', '~> 1.8' and was bitten by the change in 1.9 that removed implicitly defined field methods. It's a long story, but I ended up in a scenario where I was running bundle install without a lock file and this added on hours to an already complex refactor.

Please don't take this as angry. I'm grateful for this project and the time and effort it has saved me. I have also appreciated its gradual move towards adopting interfaces and norms that feel more familiar the avg ruby dev and I think SemVer would be another great move in that direction.