By saving the original version specified, we can warn users when a new version of the upstream provider they are using is released.
We don't want to give users warnings that they are unable to dismiss, so we won't warn them that there are new TF providers beyond the version range they specify. If they always want new provider warnings, then they can leave an open ended version constraint: >=x.y.z.
Rational:
SDKs already serve as a lock file, pinning a specific upstream version. Even if the user originally specified latest, they will need to regenerate their SDK to move to a new version. Most users won't know to do that, how would they.
Hello!
Issue details
When a user generates a source based provider, they bake in a set of version preferences:
By saving the original version specified, we can warn users when a new version of the upstream provider they are using is released.
We don't want to give users warnings that they are unable to dismiss, so we won't warn them that there are new TF providers beyond the version range they specify. If they always want new provider warnings, then they can leave an open ended version constraint:
>=x.y.z
.Rational:
SDKs already serve as a lock file, pinning a specific upstream version. Even if the user originally specified latest, they will need to regenerate their SDK to move to a new version. Most users won't know to do that, how would they.
Affected area/feature