Hi Rohit, I've tried the approach when I did the release of cloudstack-go SDK v4.15.1. I had to remove it and create v2.10.0; The reason is captured here [1] Basically, because we call our go module cloudstack/v2 if we want to have release v4.x we would need to change our module to cloudstack/v4.
I don't know how big of a deal this is to move from /v2 to /v4, on the other hand, why not get rid of the version in the module definition instead ? [1] https://github.com/apache/cloudstack-go/pull/7#issuecomment-918225329 [2] https://go.dev/blog/publishing-go-modules Regards, On Tue, Oct 19, 2021 at 3:57 AM Rohit Yadav <[email protected]> wrote: > Hi All, cc PL > > I thought to check with the community for any objections, following PL's > approach for ACS 4.15.2 we've created: > https://github.com/apache/cloudstack-go/releases/tag/v2.11.0 > > Explicit testing/voting may not be necessary as it's largely autogenerated > against API of an ACS release and further it doesn't serve purpose in > itself but currently used by the CloudStack k8s provider and terrraform > provider which will be tested/voted against (indirectly testing/voting > these projects will also validate/test the go-sdk). > > Unless there are any objections, do we agree to tag the cloudstack-go repo > with tags against ACS releases using the approach PL started? > > Regards. > > > > > > ------------------------------ > *From:* Rohit Yadav <[email protected]> > *Sent:* Wednesday, September 8, 2021 13:49 > *To:* Pierre-Luc Dion <[email protected]>; dev < > [email protected]> > *Subject:* Re: [cloudstack-go] sdk releasing > > +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 <[email protected]> > Sent: Friday, August 27, 2021 17:57 > To: Rohit Yadav <[email protected]>; dev < > [email protected]> > 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? > > > > >
