Breaking API, Versioning, and Beyond about raven-go

[onlyjob]

I'd like to support idea of assigning version numbers and tagging releases. Tags/releases are quite useful for downstream package maintainers (in Debian and other distributions) to export source tarballs, automatically track new releases and to declare dependencies between packages. Read more in the Debian Upstream Guide.

Thank you.

[titanous]

This is probably not a popular position, but I don't really believe in versioning the majority of Go packages or maintaining compatibility guarantees for them. Due to the complete uselessness of the go get toolchain, consumers of the package should be vendoring/pinning the revision, and master should always be in a working state.

[taylortrimble]

Certainly a fair point. One solution I've considered to this is saying that for now we'll just work on master and if people get unhappy about that we can revisit the issue.

Demand-driven decision. :)

[kr]

I would tend to agree with @titanous here.

[mattrobenolt]

fwiw, I planned on pinning this with gopkg.in, then moving forward. I have some pretty immediate changes I'm going to be doing that is going to break the current public API, and we'll try and message this with our users and whatnot to switch to the gopkg.in. Fortunately, there aren't a lot of raven-go users yet (compared to ruby/python/js), so I hope to make this change now before we push raven-go as an official platform we support.

[taylortrimble]

I have a bunch of breaking changes too in a pull request I've been working on for... over a year now I think? I keep getting pulled away from it, but it only has documentation left on it. I should just finish that out.

Let me know if any of my changes relate to yours @mattrobenolt.

[mattrobenolt]

Which PR?

[taylortrimble]

#19

[kamilogorek]

Closing due to inactivity and long overdue cleanup. Feel free to let me know if it's still relevant.