Semantic versioning tag for go modules

[hajimehoshi]

Would it be possible to give a tag v1.0.0 or something for go modules (formerly known as vgo)?

[pwaller]

I don't see any reason not to do this, starting from v1.0.0. @errcw, @dmitshur, @slimsag any objections?

We should try to follow semantic versioning, which means we should not introduce breaking API changes after tagging v1 unless we're willing to bump the major version number. I guess that go-gl/glow#102 is one change which will change the API slightly in a way believed to be insignificant, so maybe we should wait for that to land.

Please correct me if I'm wrong, and please file bugs if there are any other non-optimal APIs we're aware of with respect to future compatibility.

So I think we should visit tagging this once go-gl/glow#102 and #109 have landed.

We can also add a go.mod file. go mod tidy currently results in the following file:

module github.com/go-gl/gl

go 1.11

Which I think is pretty great! No dependencies! 💃

[pwaller]

PtrOffset causes "cgo argument has Go pointer to Go pointer" runtime error #80

The above issue could also be a significant API breaking change.

Sorry, understanding of it just improved, it sounds like it would not be a breaking change, but instead add additional functions, so it sounds OK.

[errcw]

No objections from me. I think semver is a good idea.