You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To ensure a specific version (range?) is used or identify of the resource as well as supporting use of different versions of the same resource, we should leverage metadata property to allow describing resource requirements like version (range), hash, etc...
Similar to the execution context for metadata, we can just have metadata at the resource level:
resources:
- name: version1type: Test/MyResourcemetadata:
Microsoft.DSC:
resourceRequirements:
version: "[1.0.0,2.0.0)"# nuget version range syntax indicating 1.x.x but not including 2.0.0properties:
a: 1b: 2
The Microsoft.DSC namespace avoids collisions, but makes it more nested. Adapters would need to opt-in to support this.
The text was updated successfully, but these errors were encountered:
For the version, I remember now that ARM has a apiversion property per resource that is required that we didn't adopt since the name didn't make sense for dsc resources. My suggestion would be to break with ARM here (since we've already broken by not having it required) and call it version and make it optional. When not specified, it's the newest one found. Otherwise, we can accept nuget version range syntax.
I think adding the optional version property to a resource instance declaration with a default of latest (or the nuget version range equivalent) makes the most sense and will be the most readable. I would rather write/maintain:
resources:
- name: version1type: Test/MyResourceversion: "[1.0.0,2.0.0)"# nuget version range syntax indicating 1.x.x but not including 2.0.0properties:
a: 1b: 2
Than the prior example, no questions asked.
The other alternative that occurs to me is appending the version range to the fully-qualified type name syntax, but I think the separate property is better.
Summary of the new feature / enhancement
To ensure a specific version (range?) is used or identify of the resource as well as supporting use of different versions of the same resource, we should leverage
metadata
property to allow describing resource requirements like version (range), hash, etc...Proposed technical implementation details (optional)
Similar to the execution context for metadata, we can just have metadata at the resource level:
The
Microsoft.DSC
namespace avoids collisions, but makes it more nested. Adapters would need to opt-in to support this.The text was updated successfully, but these errors were encountered: