[v2] Fix v1 / v2 version conflicts

[m-allanson]

• Remove plugins that are no longer needed in v2
• Update versions so that v2 versions are all newer than v1 versions
• Update peerDepencies to require Gatsby v2 and above

Ref #5891 (comment)

Edit to explain how we've updated the versions here. These new versions aim to do the following:

• ensure all plugin version numbers end with -alpha.x
• ensure any -alpha.x plugin is ahead of its non-alpha version
• ensure all plugin version numbers are one major version ahead of their Gatsby v1 version

examples:

`master` version: 1.2.3
`v2` version:     1.2.3
this PR version:  2.0.0-alpha.0

`master` version: 1.2.3
`v2` version:     2.0.5-3
this PR version:  2.0.6-alpha.0

`master` version: 2.4.2
`v2` version:     1.3.4-13
this PR version:  3.0.0-alpha.0

`master` version: 2.4.22
`v2` version:     2.4.12-10
this PR version:  3.0.0-alpha.0

`master` version: 1.0.5
`v2` version:     2.2.5-alpha.12
this PR version:  2.2.5-alpha.12

`master` version: doesn't exist
`v2` version:     2.0.1-12
this PR version:  2.0.2-alpha.0

[calcsam]

not a major version bump?

[pieh]

this seems to be v2 specific

[m-allanson]

@calcsam I updated the description to describe the rules behind the version bumps in this PR

[nihgwu]

is there any chance to land #5895 before bumping the version of gatsby-link

[nihgwu]

1. does "gatsby": ">2.0.0-alpha" is a valid pattern? can we use something like "gatsby": "2.x"

2. do we really want drop the support for v1 as some of the packages do support both v1 and v2

[m-allanson]

is there any chance to land #5895 before bumping the version of gatsby-link

We'd like to try and get a v2 beta out before merging in any more PRs as we've done a fair bit of manual testing on the current v2 branch. While still in beta / alpha I think it'd be ok to bump the version again for #5895.

does "gatsby": ">2.0.0-alpha" is a valid pattern? can we use something like "gatsby": "2.x"

I think ">2.0.0-alpha" is ok? It should pick up any 2 versions but "2.x" won't pick up alpha / beta / rc releases. Tried with https://semver.npmjs.com/

do we really want drop the support for v1 as some of the packages do support both v1 and v2

We'll still have the v1 branch and be able to publish new v1 versions of plugins. We don't have testing infrastructure to test plugins against Gatsby v1 and v2 at the same time yet (better testing infrastrucure is being worked on though). In the worst case a peerDependency mismatch will only be a warning, you can ignore it if you know the plugin is compatible.

[pieh]

this is the one I forgot about

[KyleAMathews]

Curious about the rational around doing a major release for all plugins? Not sure it matters but many/most of the plugins don't have any breaking changes. Doing major releases for them might cause more confusion as then people would want to know how to "upgrade" those plugins despite there being nothing to do.

[KyleAMathews]

Why do major version?

[m-allanson]

@KyleAMathews I think major version bumps make sense as a way of framing which plugins support which versions of Gatsby.

Some plugins support Gatsby v1 and Gatsby v2 at the moment. Once Gatsby v2 is released, our tests will be running plugins against Gatsby v2 only. If any of the plugins that support v1 and v2 stop working for v1, we won't know about it.

Bumping the major version for each plugin means we can say:

• gatsby-plugin-foo v1 is for Gatsby v1
• gatsby-plugin-foo v2 is for Gatsby v2

Or slightly trickier, but still easy to understand is:

• gatsby-plugin-bar v2 is for Gatsby v1
• gatsby-plugin-bar v3 is for Gatsby v2

I agree this could be confusing for people who'd want to know how to "upgrade" those plugins despite there being nothing to do. Made more so by our current lack of changelogs.

But I think bumping the major versions is the least confusing overall choice.

Future plugin releases will all be tested against Gatsby v2, but we can still release new versions of Gatsby v1 plugins from the v1 branch.

[pieh]

Curious about the rational around doing a major release for all plugins? Not sure it matters but many/most of the plugins don't have any breaking changes.

My reasoning for advocating for this for all packages (even if they don't have breaking changes, so not really in line with semver) is because of current workflow using lerna (releasing stable/latest from v1 and releasing next from v2). If we could easily release plugins without breaking changes to both next and latest dist-tags then I agree that we could remove major version bumps from a lot of plugins in this PR, but I just don't see how this could be managed + what @m-allanson said about making sure new stuff will be compatible with v1 would need to be done "manually".

There is also issue that some plugins that didn't have major version bump in v2 actually do have breaking changes - for example gatsby-link (with changes to pathPrefix and use of basename in react-router) so this one defenitely need a bump. This one is known - but how many are unknown? We would have to go through ~80 packages that didn't have major version bump and manually check if there was breaking changes for them in v2 but this is a) prone to errors and b) will be very time consuming and not sure if we have bandwidth to do it.

[KyleAMathews]

Ok, makes sense. Better safe than sorry.

I think we do need then a plugins section in the upgrade guide to a) add upgrade instructions for specific plugins e.g. add this new dependency to your package.json and b) say something like "Most people should not experience any breaking changes when upgrading this plugin" as there are people working on high profile sites or that are more fastidious about upgrades and will want to see an upgrade guide for every plugin the upgrade.