Open qiaozha opened 5 months ago
After rethinking, if we want to completely get rid of the apiVersion and apiVersionPolicy in the core-client-rest. we probably could take the following steps to minimize the impact.
@xirzec @joheredi how do you think?
@qiaozha this sounds like a good plan to me.
Package Name
@azure-rest/core-client
Deprecated Versions
none
Deprecation Message
not sure yet?
Why is deprecation necessary?
It's not about deprecating the whole package. Currently, we put apiVersion in the ClientOptions in core client rest https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/core/core-client-rest/src/common.ts#L331 and have a apiVersionPolicy to append the apiVersion query parameter that customer passes in the clientOptions https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/core/core-client-rest/src/apiVersionPolicy.ts#L14, however, not every operation inside a client has apiVersion parameter and even if it has, it may not be a query parameter, this is especially true for non Azure services, currently, we have add https://github.com/Azure/autorest.typescript/blob/81e09d148e33ce8d24e1746a7913782e621b8f6c/packages/typespec-ts/test/integration/generated/type/scalar/src/scalarClient.ts#L34 remove this policy logic and log a warning here to reduce customers confusion.
But we should actually get rid of apiVersion here as discussed here https://github.com/Azure/autorest.typescript/issues/2427#issuecomment-2068360031 and generate it in the client level and add the policy here if this client really does support client level apiVersion.