How to find out programmatically the api-version of a given type in the API?

[jim-minter]

Feature Request

ARM api-version is handled pretty opaquely in azure-sdk-for-go. By that, I mean that when I import, say, "github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/authorization/armauthorization/v3", I have no easy way to know programatically what api-version is being used for requests to ARM.

In fact, in that specific example, the answer is "it depends": within the same package version, the role assignments client currently uses 2022-04-01 whereas the role definitions client currently uses 2022-05-01-preview.

For requests to ARM, it is generally useful not to know or care what the api-version is, but there are exceptions.

For example, sometimes a client may want to locally persist some data retrieved from ARM, and in that case it is important to know the api-version of the object that is being persisted.

Part one of this request is: it would be really useful to be able to find that information out programmatically.

Unfortunately, this leads to a trickier follow-up issue, which is that if I bump my azure-sdk-for-go dependencies between persisting and re-reading some ARM data, I fear there's no guarantee that the more recent library will still use the same api-version as the older library, and if there is a breaking change in the API in question, my data might be read in wrong.

At the very least, if I know the api-versions of the persisted data and the library types, I can detect this issue.

More widely, it's not clear how to solve this further: as someone who wants to do this kind of thing, do I need to go to azure-rest-api-specs and generate my own clients to manage the use of api-versions more carefully myself?

[jim-minter]

@ThatJuanGuy

[jim-minter]

@jhendrixMSFT

[JeffreyRichter]

@jim-minter: Azure has a grand plan which we are very actively working on right now, but it will take some time.
The plan goes like this...

• By definition, a service is "a set of operations that version uniformly".
• Each service version gets its own docs and SDK package which version as the service versions.

So, in the future, either role assignments and role definitions will be considered a single service, and ALL their operations will version uniformly with their docs and SDK package. This means that there will be a 1:1 relationship between SDK package versions and api-version.

Or, role assignments and role definitions will be considered separate services where each will version independently along with separate docs & SDK packages versioning independently too.

The result is that you will know exactly which api-version is used when you import a specific SDK package version and therefore you will not need what you are asking for in this issue.

[jim-minter]

100% makes sense to me. Thanks!