We can document the new fields as recognised only in 1.18 (1.19? 1.20?)
API servers.
This means that clients that care that the networks fields are
recognised can use ServiceDeployWithNetworks, but existing clients can
continue to use Deploy, and eventually we should be able to deprecate
ServiceDeployWithNetworks.
This adds minimal clutter to the code, and provides the same
functionality AFAICS.
https:/ /codereview. appspot. com/76910044/ diff/20001/ state/api/ params/ params. go params/ params. go (right):
File state/api/
https:/ /codereview. appspot. com/76910044/ diff/20001/ state/api/ params/ params. go#newcode155 params/ params. go:155: type ServiceDeployWi thNetworks struct { thNetworks an alias of Deploy.
state/api/
I suggest that instead of making a new set of parameters, we could just
add the networks parameters to ServiceDeploy, and make
ServiceDeployWi
We can document the new fields as recognised only in 1.18 (1.19? 1.20?)
API servers.
This means that clients that care that the networks fields are thNetworks, but existing clients can thNetworks.
recognised can use ServiceDeployWi
continue to use Deploy, and eventually we should be able to deprecate
ServiceDeployWi
This adds minimal clutter to the code, and provides the same
functionality AFAICS.
https:/ /codereview. appspot. com/76910044/