Breaking API, Versioning, and Beyond

[taylortrimble]

Hey all!

I'm back to work on this again, and am really motivated to polish raven-go into a package that matches the client spec and has most of the same characteristics as the other raven packages. See #19, and hold me to it! 😃

However, changing API brings up a problem... go get! If we're making a few API changes that's going to be breaking people who use go get. I have some thoughts about how to manage this.

Releases and Versions

It would be nice to start tagging versioned releases with GitHub. Semver of course. I'd also like to say that we declare the package 1.0 when we match the client spec linked above.

Not Breaking

I have a small plan.

Keep breaking changes out of master for a guaranteed minimum period of time. This will make sure our go get people don't have to be integrating new changes all the time; I'd like them to like us. 😄 We can pick a breaking release schedule and set up a mailing list for reminders.

So for working on 1.0 and other breaking releases, develop in a vX branch. When it's ready to ship on schedule, we pull it into master. Anyone can get them from the tags if they're anxious for the changes ahead of schedule.

---

Feedback please! Esp. @titanous and @mattrobenolt. Thank you guys, excited to jump back into this.

[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

[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.

[kamilogorek]

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