The "type" of an resource is a relatively complicated and long string that nobody likes. E.g.:

'microsoft.compute/virtualMachines@2020-06-01'

Most new ARM Template/Bicep users don't understand the concept of resource providers and they don't know which apiVersion is the "right" one to use. It doesn't mean these things are not important, but we don't want to confuse them with information they may not need at this point.

We've already received a bunch of issues with a variety of proposals to make this type string easier to manage. I'm going to collect them all here and if/when we have a proposal for this, we will post it here first to get feedback.

Goals:

• offer a way to declare "simple" types that don't require the apiVersion to be explicitly declared (possibly aspects of the resource type as well via an alias (i.e. 'microsoft.compute/virtualMachines' => virtualMachines or vm)
  • it should still be easy to figure out which apiVersion and full rp info if I need that level of detail
• continue to expose apiVersion when it's important. If a type comes out with a new apiVersion I should not be blocked from consuming it.
• offer safe upgrades. I shouldn't be surprised that I am consuming a new apiVersion

Non-goals:

• Offer a "latest"/"auto upgrade" semantic. I think as a team we are philosophically against this. ARM templates are very stable today because of the explicit apiVersion. As long as the relevant resource type follows the rules of the ARM RPC, a working template should continue to work for as long as those APIs continue to exist.

Why this is tricky to get right

Taken from #1002 (comment);

Some things to point out about API versioning in ARM:

• API version is not a property of a resource - it defines the contract for interacting with a resource. Generally if you haven't changed any of the properties you supply, the effect on the underlying resource state will be identical between the older and newer version, unless the newer API contract has a breaking change (next point). Although it can feel odd to be using a very old API version, there is usually no great need to update unless for example you need to access some new properties added to a newer version.
• Teams are permitted to make breaking changes to the structure of the API contract between API versions. They are not permitted to make breaking changes to the structure of the API contract for an existing API version. This may mean that if you upgrade versions without changing the structure of your request, you run the risk of being unexpectedly broken at deploy time.
• Without having a known API version at authoring time, we cannot provide a great editor experience (type validation, intellisense etc), as we cannot know what properties are available.

So generally, our feeling on this is that we want to discourage people from picking up the API version at runtime and instead encourage pinning to a version and making the explicit decision to upgrade. That being said, we definitely see the need to simplify the syntax, know whether you're on the latest, and have an easy path to upgrade if you're not and want to be - currently we're thinking of addressing this with #622.

Current issues:

• Support "importing" resourceType and apiVersion mappings for specific resource types #16
• Provide support for resource provider profiles #400
• Support string interpolation in resource type string #413
• Addition of @Latest for Version and general change of APIVersion to Semantic Versioning #516
• Using latest api version of a resource #1002