URL Proposal about graphql-scalars HOT 6 CLOSED

Looks great @leebyron.

I am not sure the full semver range serves us well: Maybe just two numbers (major and minor) is enough for us to start with?

The finer semantics of "backward compatible" are not always really clear: I found it much easier to just differentiate between: you should pay attention to it (major change) and you don't need to care (minor).

from graphql-scalars.

Coming back to this after more than two year: I strongly propose to keep it as simple as possible to get started.

I created a new PR #9 with a basic setup, which I intend to merge soon and iterate on it. We will probably go with a very manual URL schema like:

spec.graphql.org/<author-name>/<scalar-name>

This would be immutable and can't be changed after merged. We will probably allow editorial changes.

A new version of the scalar would need to be have a new scalar name, which might be <scalar-name>2, <scalar-name>3 etc.

In general we will very likely rely on manual reviews to get started. If that doesn't scale we might revisit the approach.

from graphql-scalars.

Up for discussion @graphql/graphql-scalars

from graphql-scalars.

I agree with Andi's point about versioning, and might even take it a step further - if the spec change is clearly not backwards compatible, is it even the same spec at that point? Should the new spec and the old spec really be sharing usage stats? I think that for most of the metadata/stats we might want for a spec, we'd really want them per major version, not shared across multiple major versions, in which case it might be simpler to follow the golang style and just say that a new major version should just be a new spec. This would still leave a single integer version for use for editorial changes.

The obvious con here is that we might end up with https://scalars.graphql.org/andimarek/datetime-v2/1. It's a bit gross, but not actually sure if it's a huge problem?

from graphql-scalars.

I created a first implementation for this Url system: #3

from graphql-scalars.

Closing this issue as we're going ahead with immutable specifications, although we will permit non-semantic edits such as typos. See #13.

We're proceeding with @andimarek's simpler naming proposal.

from graphql-scalars.