This message was deleted.
# azure
s
This message was deleted.
t
This means that Azure doesn’t have the latest version of this resource API in this region. Replace Latest with V20200601.
Latest
version always picks the latest stable API version, which may change from one package version to the other (which it did in 0.2.8->0.3.0)
Sometimes, Microsoft publishes new versions before they are available everywhere
p
thanks @tall-librarian-49374 - as pointed out in a different thread, would be good to have some documentation about this and also to record when such a change occurs. This will allow us to monitor a single place to check if something new is available or must be present.
t
Yes, we owe you the docs about versioning.
also to record when such a change occurs
Where and how would you want to see that? Changes like this happen ~daily across all Azure API.
And we ship them in every release, including minor updates
p
What I mean, is: I would like to see that the latest changed to a new azure API version and/or that a new API version is now supported by Pulumi. Then I guess there is some way for me to check if my location already supports this version (might be a manual check) I have do myself
t
You can see this - super manually - by looking at namespaces and modules
THere’s a new namespace V20200901 under web
Which means it’s the latest now
p
ok, thanks
t
The not-yet-written guide will suggest pinning versions for long-lived infrastructure instead of using latest
p
that sounds good - I just noticed that it is still hard to figure out which of the versions is the latest (might be a problem of my editor). I know its more less a date string, but comparing by eye is not always easy.
t
t
@prehistoric-nail-50687 Do you think something like this would help?
p
I understand the reasoning behind this, but it somehow feels wrong to polluts the source with version definitions all over. Also I don’t know if it is a good thing to switch between different versions the same program, e.g. is it always fine to create a resource A with version 1 and have depending resource B created with version 2? Could this potentially create some problems?
t
is it always fine to create a resource A with version 1 and have depending resource B created with version 2?
Yes. You kind of have to do that all the time: every resource has its own set of versions, so there isn’t one API version to fit all resources. Besides, no matter which API version you use for a given type - it’s going to be the same resource in Azure in the end.
👍 1