2bf0d38236
Jeff has pointed out that the current practice in the SDK of having a ServiceVersion which contains the current API versions of the service (for instance:
```c++
class ServiceVersion final {
public:
explicit ServiceVersion(std::string version) : m_version(std::move(version)) {}
AZ_STORAGE_QUEUES_DLLEXPORT const static ServiceVersion V2018_03_28;
AZ_STORAGE_QUEUES_DLLEXPORT const static ServiceVersion V2020_10_01;
};
)
```
Has a problem because the `ServiceVersion` construct has an implication that each of the `ServiceVersion` values listed is fully supported by the SDK.
The reality is that the SDK client team only tests the most recent API version listed in the SDK (the value which is the default version listed in the `ServiceClient` constructor).
How do we resolve this issue?
There are a few possible solutions that we’ve explored:
1) Test all the API versions listed in the `ServiceVersion` enumeration.
2) Remove the unsupported values from the `ServiceVersion` enumeration.
3) Remove the `ServiceVersion` enumeration
4) Remove the ability to set the API version at all.
Each of these solutions has some fairly significant drawbacks.
1) Test all the API versions listed.
The core problem with this is that the SDK team is small and adding tests to support every possible API version is going to be prohibitively expensive.
2) Remove the unsupported values from the `ServiceVersion` enumeration.
This is a breaking change and it means that moving to a new API version requires a breaking change to the SDK, even if the changes between API versions is strictly additive.
3) Remove the ServiceVersion enumeration.
This is also a breaking change for shipping SDKs (specifically KeyVault and Storage Queues). However, it is a one-time breaking change and we don’t have evidence of customers actually using the feature.
4) Remove the ability to set the API version at all.
Having *some* mechanism to set the API version is an important “escape hatch” which will allow customers to specify a specific API version even if that API version is not fully supported.
After discussing this a LOT, [@Ahson Khan](mailto:ahkha@microsoft.com), [@Rick Winter](mailto:Rick.Winter@microsoft.com), [@Jeffrey Richter](mailto:jeffreyr@microsoft.com), [@George Arama](mailto:George.Arama@microsoft.com), and [@Larry Osterman](mailto:Larry.Osterman@microsoft.com) came to the conclusion that we should probably take option #3, but leave the ClientOptions.Version value as a std::string.
|
||
|---|---|---|
| .. | ||
| attestation | ||
| core | ||
| identity | ||
| keyvault | ||
| storage | ||
| template | ||