Open nagyesta opened 6 months ago
Hi @nagyesta! With each release we generate from a specific service version. Could you use an older version of the SDK? For example, if you need to use service version 7.4 you can use v1.0.0 of the SDK.
Is there a particular reason why you need this feature? There shouldn't be any breaking changes between minor version releases of the SDK.
Hi @nagyesta. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.
Hi @gracewilcox , thank you for looking into this and thank you for the additional details!
I realize, that my case might be fairly uncommon and I should have shared more context to make it more compelling. Sorry for not doing so in my initial post!
I need this feature, because I am the developer of an Azure Key Vault test double. As part of this effort, I am providing example code, just like the snippet I have shared above, to let our users (i.e., people who are using both Azure Key Vault, your SDK and my test double) see how they need to configure their tests when the test double is used. As a result, I must consider their reasons too and let them use the latest SDK versions when possible, so that they can benefit from all the great features and improvements you are including in these SDKs. I assume the list would contain the following items:
Since the test doubles are always one step behind the official API changes, whenever the new API version is released (or in the Go SDKs case being prepared) and the API version parameter changes, the test double needs to be updated to support the requests which are sent to the new API. While this is not done, the people using the SDK might need to make a choice to either use the latest SDK version to benefit from the items above, OR test their code using their existing pipeline. This is not a great trade-off to make in my opinion.
With that in mind, I have started to look for a way to override the API version similarly to the way the other official SDKs support it (.Net, Java, Python, NodeJS) and I have found this option:
https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/azcore/policy/policy.go#L35-L37
As I have read the comment, I assumed, that the intention is in fact to allow overriding the version, but as soon as I have attempted it, I have received the error I mentioned in the ticket. With this, I assumed that it must be an unintended limitation or bug as only the Go SDK is behaving like this, the others allow setting it to the known service version without issues.
What do you think? Would it make sense to support the API version override considering these?
Thank you again for your efforts!
Hi nagyesta! Sorry for the late response, we've discussed this new feature as a team and decided to add it for Key Vault. We're discussing where to fit the work in in the next semester planning.
Hi @gracewilcox , thank you! That is great news!
Feature Request
When a new client version is released because support is added to a new Azure Key Vault API version (like in case of the recently added 7.5 API support), the default API version is always the latest.
Since setting API Version is not possible, I am not able to continue using the 7.4 API if I want to.
I have tried setting the APi version like this:
Which generated this error:
Assuming, that this is the intended way to set the API version, could you please add support to API version overrides?
I can understand if it can be only set to certain values ("7.2", "7.3", "7.4", "7.5", etc.), but it would help me reduce the number of times my build breaks if I had a way to set the API version to not use latest.
Would this be possible?
Thank you in advance!