It's a bit of a dilemma whether we can push the major version of the API client or not. The initial plan was to try to keep the API client base version in sync with Koios /api/v0|V1 and Koios v1.x.x. However, Koios v1.x.x has added and will add new breaking changes, as a result of which we should update the major version of the library according to good practices and Semantic Versioning. Given the quirks of Golang's compatibility promise, a major release should not contain any breaking changes. We wouldn't want anyone's production application to fail to compile due to a violation of this promise. Since the import path of the library changes with the major version, the ideal scenario would be the following.
// Koios v1.x.x | `/api/v0` and `/api/v1`
import "github.com/cardano-community/koios-go-client" // imports as package "koios"
// Koios v2.x.x | `/api/v2`
import "github.com/cardano-community/koios-go-client/v2" // imports as package "koios"
// Koios v3.x.x | `/api/v3`
import "github.com/cardano-community/koios-go-client/v3" // imports as package "koios"
// etc.
So there are two ways to proceed.
Do break this promise for now and hope we get the API stable enough for future major releases.*
this would mean that any project using this library may experience situations where a normal library update prevents them from compiling the project and the only options are to refactor their code based on library changes or to bind their dependency to a specific Git commit.
We push forward a major version of the library regardless of the Koios api version whenever a breaking update is introduced.
This may result somthing following:
Description
It's a bit of a dilemma whether we can push the major version of the API client or not. The initial plan was to try to keep the API client base version in sync with Koios /api/v0|V1 and Koios v1.x.x. However, Koios v1.x.x has added and will add new breaking changes, as a result of which we should update the major version of the library according to good practices and Semantic Versioning. Given the quirks of Golang's compatibility promise, a major release should not contain any breaking changes. We wouldn't want anyone's production application to fail to compile due to a violation of this promise. Since the import path of the library changes with the major version, the ideal scenario would be the following.
So there are two ways to proceed.
The most likely problem with 2nd approach is that it makes it difficult to distinguish between a library version and a supported Koios API version.
Any opinions / proposals how we should move forward?
Related to PR #34