-
Notifications
You must be signed in to change notification settings - Fork 91
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
add RMFR8 - Category: Composition - End-of-life resource versions #1419
Conversation
Important The "Needs: Triage 🔍" label must be removed once the triage process is complete! Tip For additional guidance on how to triage this issue/PR, see the AVM Issue Triage documentation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some more suggestions
When a given version of an Azure resource used in a resource module reaches its end-of-life (EOL) and is no longer supported by Microsoft, the module owner **MUST** ensure that: | ||
|
||
1. The module is aligned with these changes and only includes supported versions of the resource. (This is typically achieved through the allowed values in the parameter that specifies the resource version.) | ||
2. The following notice is shown under the `Notes` section of the module's `readme.md`. (If any related public announcement is available, it can also be linked to from the Notes section.): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this would be much better in the releases section. After a while this change will be commonplace and not needed in a readme file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please clarify which releases section you're referring to? I agree to your point this information becoming obsolete over time and having a good practice for handling its relevance accordingly - but the notes section might be the most obvious place for this that is attached directly to the module. Also, having the blurb in both point 2 and 3 was agreed on in our weekly call, so I would just go with it. To incorporate your PoV though, I think we could add a time stamp and/or mention the version, so it is clear. What do you think?
2. The following notice is shown under the `Notes` section of the module's `readme.md`. (If any related public announcement is available, it can also be linked to from the Notes section.): | ||
> "Certain versions of this Azure resource reached their end of life. The latest version of this module only includes supported versions of the resource. All unsupported versions have been removed from the related parameters." | ||
3. AND the related parameter's description: | ||
> "Certain versions of this Azure resource reached their end of life. The latest version of this module only includes supported versions of the resource. All unsupported versions have been removed from this parameter." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think number 3 is necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was also agreed on internally, I just ended up being the one writing it down. :) I think having it in the parameter makes sense, as there's no way not to see it - this was probably the main argument of whoever came up with it.
Co-authored-by: Matt White <[email protected]>
Overview/Summary
RMFR8 - Category: Composition - End-of-life resource versions
This PR fixes/adds/changes/removes
Breaking Changes
n/a
As part of this Pull Request I have
main
branch