Addition of @Latest for Version and general change of APIVersion to Semantic Versioning

[ChristopherGLewis]

Version management in Azure and general programming has always been a problem. Bicep's use of @APIVersion is obviously tied to the Azure Resource APIVersion field. Maintaining older templates' APIVerison is time-consuming and error-prone.

Bicep currently uses @APIVersion as a required component within the Resource Type field. While versioning the resource type is important in its own right, it would also be nice to use @Latest to ensure that your resource is using a resource type that is not out of date. (I have encountered issues with deploying older APIVersion resources to Azure resulting in unexpected behavior (specifically VM extensions on Linux.)

Unfortunately, the best approach to this would be to convert APIVersion into Semantic Versioning like the AZ CLI and the AZ Powershell Module. This way we could tag a resource type to a major/minor version and seamlessly allow for bug fixes.

• Microsoft.Storage/storageAccounts@Latest <- Latest
• Microsoft.Storage/storageAccounts@2.3.1 <- Full reference to major.minor.patch
• Microsoft.Storage/storageAccounts@2.3 <- Use latest patch of 2.3 release
• Microsoft.Storage/storageAccounts@2 <- Use latest minor release of 2.3

I would suspect there's no easy way to reference non-breaking changes with the current APIVersion format.

Unfortunately, this would require re-working all of Azure Resources to support this, along with all API's and SDKs and would break tons of 3rd party products.

[alex-frankel]

#16 and #413 are both relevant to this discussion. should probably combine these at some point. Look at #413 for feelings on "latest" :)

I think you hit it right on the head with semantic versioning. The date strings are just confusing. Sometimes a 2015-preview version is the right one to use, sometimes a 2019 version is out of date. You are also right that at this point, it's likely not realistic to change the versioning scheme.

I think we can probably do what the apiProfile property in ARM templates do today, and make that semantic, but that would be global for all resources in the file. We could still allow for overrides at the individual resource level if it was important. So something like:

// mapping to a defined set of api versions for every resource type
version = 2.0.1
// could also provide "go to def" support which would show you the full list if you were curious

// per version 2.0.1, maps to 2019-01-01
resource stg microsoft.storage/storageAccounts = { ... }

// override to more recent version if needed
resource stg2 microsoft.storage/storageAccounts@2020-09-01 = { ... }

thoughts?