Conversation
Clarified naming convention for new Custom Scalar versions.
|
We thought about it, but decided against it. The name in the URL is just a name for the spec: of course often the name mirrors a recommendation for the actual Scalar, but it doesn't enforce/require it Introducing a pattern for versions is unnecessary and complicates the URLs and also the decision contributors need to make: is my new Date time scalar spec a v2 of the old one or is a new one? I see Scalars spec are immutable (minus typos/editorial fixes) and you don't "fix" them, you can evolve them into a new Spec, but then you need to give it a new name (and you are free to choose any name). By leaving the nam clearly in the contributors responsibility we make this clear. If they really want to name a new spec -v2 they can, but there is not inherent "versions" of Scalar specs and I still think this is true. |
|
Ok so if I understand correctly, the name in the spec, such as I can do something like this today if I want to? # DateTime is the recommended name but I'm free to use what I want in my schema
scalar MyLocalDateTime @specifiedBy(url: "https://scalars.graphql.org/andimarek/date-time.html")Then I'm fine 👍 I can do stuff like |
|
@martinbonnin Yes that is correct. |
|
@andimarek sounds good 👍 Thanks for explaining! I'll send a PR to the README in a bit to hopefully make that more explicit. |
|
Follow up PR is there: #35 |
Opening this for discussion. Ideally we don't need version at all but if we do, I find
https://scalars.graphql.org/andimarek/v2/date-time.htmlto be easier to process thanhttps://scalars.graphql.org/andimarek/date-time-2.html