+1 That makes sense. In the go-sdk we've a generator that consumes the listApis output of a ACS release and generates the library - https://github.com/apache/cloudstack-go/tree/main/generate
I suppose for every ACS release, we can update go-sdk with release-specific API list, test it, release and tag it. Even automate this? I would say - no need to vote it unless the SDK is manually changed. Since it is used with the k8s provider or the terraform provider so tags on go-sdk may go in-line with tags/release of these users. Regards. ________________________________ From: Pierre-Luc Dion <pdion...@apache.org> Sent: Friday, August 27, 2021 17:57 To: Rohit Yadav <rohit.ya...@shapeblue.com>; dev <dev@cloudstack.apache.org> Subject: [cloudstack-go] sdk releasing I've messing around with cloudstack-go Did a fix that rohit merged yesturday for hostsservices, but this fix will only work for acs4.15, I'd like to fix it for previous acs version too, but look like the version of the SDK depend on acs version; Example; for the hostservices, the host attribute managementserverid is a UUID in 4.15, but an integer in an older version of xenserver. This breaks the structs,or map, we must have some other similar issue. so I'd like to help on creating a tag or version of the SDK so they would match acs version target, ie: SDK version = v4.15-0; where the last digit would define the sdk version or increase with fixes. Current versioning in use = https://github.com/apache/cloudstack-go/releases The issue I'm expecting to face is if we create a release , let's say v4.15-0 from main branch today, if we want to create v4.14.0, it will not be possible from the main branch because we need to revert the last commit but also fix hostservices. Here are a bunch of questions I have: 1. Should we create a branch for older ACS versions and keep main for latest fixes and future releases ? 2. Do we need to vote for such changes? 3. Does such releases could impact other Go projects that use this one, such as terraform and kubernetes drivers? 4. Should we provide similar versioning on our kubernetes driver?
