Add `implementedBy` field in `metadata.yml`

[magicmark]

@PascalSenn suggested at today's wg meeting that GAPs should list (in metadata.yml) what servers/clients implement the spec, so users can decide which spec to use.

Option 1 - text only

implementedBy:
  - "Apollo Client >= v1.2.3"
  - "Relay >= v3.4.5"

Option 2 - markdown links

implementedBy:
  - [Apollo Client >= v1.2.3](https://www.apollographql.com/docs/react)
  - [Relay >= v3.4.5](https://github.com/facebook/relay)

Option 3 - structured data

implementedBy:
  - name: Apollo Client
    website: https://www.apollographql.com/docs/react
    version: 1.2.3
  - name: Relay
    website: https://www.apollographql.com/docs/react
    version: 3.4.5

Option 4 - project definition keys + structured data

implementedBy:
  - project: apollo-client
    version: 1.2.3
  - project: relay
    version: 3.4.5

...which refers to some central projects.yml that looks like this:

- id: apollo-client
  website: https://www.apollographql.com/docs/react
- id: relay
  website: https://github.com/facebook/relay

Maybe this can reuse the definitions list here https://caniuse.graphql.now/index.html#projects

Note: I'd also like to support arbitrary projects here too, since support might initially be implemented as random a plugin (e.g. the @mock spec is currently implemented in apollo-client-mock-directive-plugin, not apollo core. I would expect many specs might start out this way.

So that implies something like this:

implementedBy:
  - project: relay
    version: 3.4.5
  - name: apollo-client-mock-directive-plugin
    website: https://github.com/magicmark/apollo-client-mock-directive-plugin/
    version: 0.0.1

---

my vote is Option 4.

[martinbonnin]

My vote goes to Option 4 with a few tweaks:

implementedBy:
  - project: apollo-client
    since: 1.2.3
    note: "[read the docs](https://....)"
    partial: true
  - project: relay
    since: 3.4.5
    note: "supported since 3.0.0 but had an issue with XYZ"

Then I can reuse from caniuse :)

[magicmark]

awesome! @martinbonnin is it worth packaging up the projects.yaml in a shared package? or even just a well known file in a github repo that I can curl at build time

[martinbonnin]

is it worth packaging up the projects.yaml in a shared package? or even just a well known file in a github repo that I can curl at build time

Definitely, would be quite helpful

[magicmark]

or maybe even https://landscape.graphql.org/projects.yml ?

[martinbonnin]

I would keep it in this repo I think. The landscape repo is watched by a bunch of people who might not want our constant updating of the list in their notifications.