@mjmahone There are a few breaking changes that were merged into master since 0.13.2. The biggest breaking change is #1284 but there is also #1274 and #1277.
Not sure that that bumping version to 0.13.3 would be enough.

@mjmahone Not directly related to this PR. But I think we need to have a special label for all PR with breaking changes. I got this idea from mocha repo:

I went ahead and added such label to a couple open PRs.
What do you think about this mechanism?

Yeah I think that's a good idea, especially if it is enforced on PRs themselves: we wouldn't pull in PRs that have semver-major changes until just before we'd want a new major version released.

:/ I unfortunately simultaneously really need to bump a version, don't want to break people currently on 13.2, and don't have the knowledge yet to pull in many semver-major changes in preparation for the 14.0.0 release. I may have to disrupt @leebyron's plans a bit and bump this to 0.14.0 (treating it as a minor, yet still backwards-incompatible, bump), and let the major release start with 15.0.0.

I may have to disrupt @leebyron's plans a bit and bump this to 0.14.0 (treating it as a minor, yet still backwards-incompatible, bump), and let the major release start with 15.0.0.

I think it's best possible solution in the current situation 👍

@mjmahone I don't think there are any critical PRs that should be merged before release, except for #1353 which fixes CI for node v9.
Also, it would be nice to include babel7 migration (#1338 and #1350) in this release since it was long planned and block other improvements to build system, e.g. #1348

Let's wait on this - we published that the next version would be v14 and we've merged some breaking changes.

In fact - why not just update this to be a v14 bump instead

0.13.0 -> 0.14.0 is semver equivalent - starting with 0. effectively treats the next number as a major breaking. I'm not sure it's necessary to release 0.14 instead of 14.0? Why bother with changing plans?

Yeah I think we should move to 14.0 based on this discussion. Not sure though what is necessary to get there: were there other breaking changes we need to pull in?

@mjmahone @leebyron I think people wanted 14.0.0 to solve the issue with incompatible peerDependencies. But 14.0.0 will be the improvement in that sense only if we don't plan to release 15.0.0 in foreseen future.

So I think we should review all proposed breaking changes that we have at the moment and either reject or merge them.
For example #1324 propose to make graphql-js spec compliant but it's a breaking change at the same time.
I can review all issues/PRs and compile a list.

To minimize possible risks I think we need to make 14.0.0-rc.1 release similar to 0.13.0-rc.1.

I also think it would be great if release notes for 14.0.0 would contain deprecation notice and define sunset version (15.0.0 or other) for:

• legacy SDL syntax
• allowedLegacyNames
• onOperation, onFragment, onField
• isValidJSValue,isValidLiteralValue,introspectionQuery