I’m interested in plans for versioning and compat.
In terms of making PR requests for format changes to existing endpoints, do you have any plans for how versioning will be handled to not-break backwards compatibility for existing clients? What are your existing thoughts on this, and do you think its possible/reasonable to do while also adding the huge list of functional things people want from the API?
Would it be best to make a PR proposal for the ability to specify the specific endpoint version you want to use per-request and changes to?
(Typed out a longer post but the forums swallowed it)
This is a longer-term question, we don’t have a complete answer yet. I’d like to move to that model after we’ve plumbed more of the data through, I just don’t know how we’d support that sanely within our codebase. I also haven’t seen any implementations of a model like that in an API I’ve used/investigated so I don’t know what sort of best practices we should follow.
I’d write up your proposal in a forum post or gist, it’s too long-term of an idea for a PR to be very useful right now. After we’ve gotten over the hump of exposing most of the useful/interesting data available I’d like to circle back around on a consistency pass that would potentially include a more flexible versioning story.
In terms of the current /v2 API, once we ship the API it won’t have fields deleted or renamed. We may add fields as more data becomes available.