ire-and-curses
commented
5 years ago Notes:
- if we're doing semver then I think we're going to have to get more comfortable with major version bumps. This is because we're being driven by protocol changes that will regularly force our API to change, even if we try to minimise change from a usability perspective.
- we need to get Horizon and the SDKs on the same page. It's not right that we're doing small version bumps in Horizon (and pretending we're not production yet) and forcing major bumps in SDKS. This one is on me to make the v1 Horizon proposal for us to discuss
- I think we should change our approach to deprecations in Horizon, and try and bundle them a little more, rather than picking a point like "removed in 2 releases time". In most cases there's not much urgency to the deprecations, other than that they are annoying. That's then an easier thing to explain to SDKs, and reduces the churn on the API.
- We need to clarify our deprecation process so that the SDKs can clearly state what's going to change with appropriate notice. This one's also on me to propose something.
- We could use beta releases as a way for SDKs with new features to be released (for use on testnet) prior to pubnet upgrade.
Horizon needs a deprecation policy that takes account of the tight coupling between the REST API and the SDKs, so that all parties have clear and reasonable warning of breaking changes. This will allow SDKs and their users to plan appropriately.