v2.15.0 breaking change regarding displayText handling for CreateNetwork

[hrak]

PR #53 introducing CS 4.18 support removed displayText as a parameter to NewCreateNetworkParams(). This makes sense when talking to CS 4.18 (the parameter is no longer mandatory in CS 4.18), but when talking to CS < 4.18, this introduced a breaking change in the old behavior, resulting in Unable to execute API command createnetwork due to missing parameter displaytext.

cloudstack-go/cloudstack/NetworkService.go

Line 1103 in 3995b5e

func (s *NetworkService) NewCreateNetworkParams(name string, networkofferingid string, zoneid string) *CreateNetworkParams {

I am not entirely sure whether this is something that needs to be fixed here, or in implementations of cloudstack-go, but its a undocumented breaking change nonetheless.

[shwstppr]

@rohityadavcloud @hrak what should be the way forward here? With each ACS release, there will be some breaking changes so should we try to maintain backward compatibility or should we document them?
Even with the current 4.19 support, there are many such changes. Eg: https://github.com/apache/cloudstack-go/pull/76/files#diff-b5f2881ff8e94586b79e300b43bb24a69303821045c600afc70b0ce265141bcdL460-R460

[rohityadavcloud]

Since this is optional in newer versions but not removed, the go-sdk can still call/pass it?

[weizhouapache]

Since this is optional in newer versions but not removed, the go-sdk can still call/pass it?

@rohityadavcloud
as understand, the main problem is, users have to adapt their code for the newer version, which cause backward compatibility

for example, with old go-sdk, they can create networkACL parameter by

params := cloudstack.NetworkACLServiceIface.NewCreateNetworkACLListParams(name, vpcId)

now they have to use

params := cloudstack.NetworkACLServiceIface.NewCreateNetworkACLListParams(name)
params.SetVpcId(vpcId)

Both methods should be supported.

[rohityadavcloud]

Agree @weizhouapache - ideally only the older method should be supported. However, we don't promise backward compatibility with the go-sdk, your proposal makes sense.

[shwstppr]

@rohityadavcloud @weizhouapache @hrak I looked into generate code and currently I didn't find a way to effectively find such breaking changes. Maybe we need to use two listApis.json - one latest and one from the previous release to address such breaking changes. Any ideas?
Would it make sense to continue 2.16.0 release while we work on this issue? We can create a new release once this is fixed.

[weizhouapache]

@shwstppr
to keep backward compatibility, can we manually add the methods which are removed by #76 ?
(keep both new and old methods)

[shwstppr]

@weizhouapache okay I'll add those removed methods

[rohityadavcloud]

Agree with @weizhouapache, cc @shwstppr

[shwstppr]

@weizhouapache @rohityadavcloud I've created #77 to restore breaking changes from ACS 4.19. Do we need to do it for 4.18 as well since this issue relates to that?

[shwstppr]

Closing this based on recent changes and provision for forcing params to be required in #79
@hrak please reopen if we need further work.