-
Notifications
You must be signed in to change notification settings - Fork 730
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Addition of @Latest for Version and general change of APIVersion to Semantic Versioning #516
Comments
#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
thoughts? |
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.
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.
The text was updated successfully, but these errors were encountered: