versioning strategy about graphql HOT 4 CLOSED

Thanks @EmergentBehavior for bringing this up 👍🏻

Too bad someone else already squatted on https://github.com/go-graphql/ for a long time now; we could have gotten gopkg.in/graphql.v0.

I was too late and only managed to snag github.com/graphql-go.
So we ended up with gopkg.in/graphql-go/graphql.v0, which isn't that bad lol

There are several things we can discuss to kick things off:

Semver

• We should at least agree on semver for versioning (e.g. v1.2.3), right?

Branch vs tags?

• Example of a versioned package using tags: https://github.com/tylerb/graceful
• Example of using branch: https://github.com/go-mgo/mgo

Internal import paths

We can encourage users to use the versioned package import e.g gopkg.in/graphql-go/graphql.v1 in the README and examples, but internally for our code base, do we want to use gopkg.in/graphql-go/graphql.v1 or github.com/graphql-go/graphql?

Again, graceful and mgo shows two different approaches.

Cheers!

from graphql.

Strongly recommend going with semver. and have always preferred using branches over tags, but of course we should see what everyone is comfortable with.

Internally, I think it may make more sense to use the github.com path. With gopkg.in, v0 will point to master, but once there is a major version pushed, e.g. v1, it will always point to the latest semver of that branch (e.g. 1.1.2, 1.9, etc.). This could cause confusion during internal development.

from graphql.

Its probably also worthwhile considering how to clearly show which versions of graphql-go track against versions of the graphql spec.

from graphql.

@mleonard87 thanks for bringing it up! — let's have the graphql-js version parity on each release's description; closing this one and let's continue the conversation on new issues.

from graphql.