I've taken a time-boxed pass at upgrading the stellar/go dependency from horizonclient-v3.0.0 to horizonclient-v8.0.0. I mostly just wanted to explore, understand, and validate assumptions about how Kelp could be upgraded, assuming that the upgrade path would not be smooth.
The intention was to understand, not necessarily deliver an upgrade.
I've opened this draft PR to have this change run on Kelp's CI, to see if at least from CI's perspective if this idea for how to make the upgrade happen, has substance or creates more problems than it solves.
The approach I've taken is to:
Upgrade github.com/stellar/go.
Preserve use of the old github.com/stellar/go@horizonclient-v3.0.0/build by vendoring that package inside of kelp.
Update references to types and functions within github.com/stellar/go/xdr to their new names, since some XDR types had their names changed.
This PR is a draft and is likely incomplete.
I've taken a time-boxed pass at upgrading the
stellar/go
dependency fromhorizonclient-v3.0.0
tohorizonclient-v8.0.0
. I mostly just wanted to explore, understand, and validate assumptions about how Kelp could be upgraded, assuming that the upgrade path would not be smooth.The intention was to understand, not necessarily deliver an upgrade.
I've opened this draft PR to have this change run on Kelp's CI, to see if at least from CI's perspective if this idea for how to make the upgrade happen, has substance or creates more problems than it solves.
The approach I've taken is to:
github.com/stellar/go
.github.com/stellar/go@horizonclient-v3.0.0/build
by vendoring that package inside of kelp.github.com/stellar/go/xdr
to their new names, since some XDR types had their names changed.Maybe fix #741