Go SDK versioning pattern appears volatile

[edmc-ss]

In utilizing the import pattern github.com/oracle/oci-go-sdk/v65/..., I'm fixing (in the import line itself) at least a range of git tags (releases) in the 65.XX.YY range (pinned by our go.mod/go.sum of course). But a more familiar pattern would be for me to simply import github.com/oracle/oci-go-sdk" and let my module reference and/or go get command pin whatever release/module version I want. And, yet, if I just go get github.com/oracle/oci-go-sdk@latest`, I get something well out of date (~ 4 years).

Any plans on improving this experience?

Moreover, if we can follow the versioning strategy of the SDK as V.., convention might suggest no breaking changes within the same number. And, yet, there have been some.

Could you kindly advise what importers of this Golang SDK should do in our client code?

[ZiyaoQiao]

Thank you for your feedback. Unfortunately, we cannot make the requested change due to Go's module versioning strategy. The OCI Go SDK initially followed the standard Go versioning approach before Go Module was introduced, which involved bumping the major version for any incompatibility changes.

With the introduction of Go modules, this approach led to challenges, as Go's import rules require specifying the major version for compatibility. While we understand this can be a pain point, transitioning our project to github.com/oracle/oci-go-sdk without a version indicator is not feasible.

We revised our versioning strategy a few years ago to minimize disruptions: Versioning Strategy Update. We hope this is a one-time adjustment for you to change the updated import pattern to github.com/oracle/oci-go-sdk/v65.

Thank you for your understanding, and we appreciate your continued support.

[edmc-ss]

Hmm... it's a little confusing in that link... It sounds like breaking changes in "client" code will only bump to x.y+1.z whereas breaking changes in "common" code will bump to x+1.y.z. I guess there is a reason for this... but as I'm using both oci-go-sdk/v65/common and oci-go-sdk/v65/objectstorage, is the 2nd one ("objectstorage") considered "protected" by that x+1.y.z rule (i.e. it is "common" code as well)?

[ZiyaoQiao]

No matter which module you use, the Go SDK's versioning remains consistent across different modules. If there's ever a breaking change in the common code, we increment the major version—for example, to v66. In such cases, all imports, including object storage, identity, etc., would need to reflect this update.

Fortunately, breaking changes in the common code have been rare over the past year, and we strive to maintain compatibility as much as possible. At this time, you can continue using v65 in your imports without much concern about frequent major version changes.

[edmc-ss]

Sounds great! I'll just assume my last query about the subdir "objectstorage" being in the "common", not "client", category is true. Feel encouraged to resolve/close this issue.